From tls-bounces@lists.ietf.org Sun Jul 01 00:03:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4qe9-0006ro-Ab; Sun, 01 Jul 2007 00:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4qe8-0006rj-41 for tls@ietf.org; Sun, 01 Jul 2007 00:02:48 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4qe4-0007EO-Tg for tls@ietf.org; Sun, 01 Jul 2007 00:02:48 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 654892EF for ; Sun, 1 Jul 2007 00:03:06 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 368DE5B32B for ; Sun, 1 Jul 2007 00:03:06 -0400 (EDT) Message-ID: <468726A2.8040909@pobox.com> Date: Sat, 30 Jun 2007 20:59:30 -0700 From: Mike User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Signature Hash Agility References: <20070629160611.750F933C1A@delta.rtfm.com> <4686B8E0.2080709@pobox.com> <20070630210724.250E333C1A@delta.rtfm.com> <4686CE24.9050207@pobox.com> <20070630215839.27BB633C1A@delta.rtfm.com> In-Reply-To: <20070630215839.27BB633C1A@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org > You're kidding, right? The server is about to do a digital signature. > The cost of searching through a list of probably < 5 entries to > look through your preferred choice (when your list is probably <5 > entries) is totally trivial by comparison. Well there have been suggestions to change from a list of hash algorithms to a list of signature algorithms which means the list will be longer, and then there was a suggestion to send I believe it was DigestInfo ASN.1 structures which would need to be processed. But yes that is probably trivial compared to doing the signature. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jul 01 11:05:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I50yx-0001Kx-P4; Sun, 01 Jul 2007 11:04:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I50yw-0001Kp-GW for tls@ietf.org; Sun, 01 Jul 2007 11:04:58 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I50ys-0006dA-6o for tls@ietf.org; Sun, 01 Jul 2007 11:04:58 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 0C09E33C1A; Sat, 30 Jun 2007 22:10:55 -0700 (PDT) Date: Sat, 30 Jun 2007 22:10:54 -0700 From: Eric Rescorla To: Mike Subject: Re: [TLS] Signature Hash Agility In-Reply-To: <468726A2.8040909@pobox.com> References: <20070629160611.750F933C1A@delta.rtfm.com> <4686B8E0.2080709@pobox.com> <20070630210724.250E333C1A@delta.rtfm.com> <4686CE24.9050207@pobox.com> <20070630215839.27BB633C1A@delta.rtfm.com> <468726A2.8040909@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: <20070701051055.0C09E33C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org At Sat, 30 Jun 2007 20:59:30 -0700, Mike wrote: > > > You're kidding, right? The server is about to do a digital signature. > > The cost of searching through a list of probably < 5 entries to > > look through your preferred choice (when your list is probably <5 > > entries) is totally trivial by comparison. > > Well there have been suggestions to change from a list of hash > algorithms to a list of signature algorithms which means the > list will be longer, and then there was a suggestion to send > I believe it was DigestInfo ASN.1 structures which would need > to be processed. But yes that is probably trivial compared to > doing the signature. The DigestInfo ASN.1 structures need to be transmitted regardless of what the ordering rules are. They are there to prevent substitution attacks on the signature. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 02 09:52:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MK7-0001sY-Q1; Mon, 02 Jul 2007 09:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MK6-0001sT-6o for tls@ietf.org; Mon, 02 Jul 2007 09:52:14 -0400 Received: from static-64-115-150-146.isp.broadviewnet.net ([64.115.150.146] helo=homer.ntru.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5MK2-0000YD-Sc for tls@ietf.org; Mon, 02 Jul 2007 09:52:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Signature Hash Agility Date: Mon, 2 Jul 2007 09:52:14 -0400 Message-ID: In-Reply-To: <20070701051055.0C09E33C1A@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Signature Hash Agility Thread-Index: Ace78TbyeknnudtmSSqpSD06CSnDNgAvnnKA References: <20070629160611.750F933C1A@delta.rtfm.com><4686B8E0.2080709@pobox.com><20070630210724.250E333C1A@delta.rtfm.com><4686CE24.9050207@pobox.com><20070630215839.27BB633C1A@delta.rtfm.com><468726A2.8040909@pobox.com> <20070701051055.0C09E33C1A@delta.rtfm.com> From: "Whyte, William" To: "Eric Rescorla" , "Mike" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org > The DigestInfo ASN.1 structures need to be transmitted regardless > of what the ordering rules are. They are there to prevent=20 > substitution attacks on the signature. Burt Kaliski has a presentation about this approach, which he calls "Hash Function Firewalls". You can download the presentation in various formats from http://grouper.ieee.org/groups/1363/Research/Presentations.html (sorry no direct link -- bottom of the page). There are various downsides to these firewalls and it's not clear that they absolutely need to be included if a system's being designed from scratch. Cheers, William > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 > Sent: Sunday, July 01, 2007 6:11 AM > To: Mike > Cc: tls@ietf.org > Subject: Re: [TLS] Signature Hash Agility >=20 > At Sat, 30 Jun 2007 20:59:30 -0700, > Mike wrote: > >=20 > > > You're kidding, right? The server is about to do a=20 > digital signature. > > > The cost of searching through a list of probably < 5 entries to > > > look through your preferred choice (when your list is probably <5 > > > entries) is totally trivial by comparison. > >=20 > > Well there have been suggestions to change from a list of hash > > algorithms to a list of signature algorithms which means the > > list will be longer, and then there was a suggestion to send > > I believe it was DigestInfo ASN.1 structures which would need > > to be processed. But yes that is probably trivial compared to > > doing the signature. >=20 > The DigestInfo ASN.1 structures need to be transmitted regardless > of what the ordering rules are. They are there to prevent=20 > substitution attacks on the signature. >=20 > -Ekr >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 02 17:15:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5TFP-0006kM-9P; Mon, 02 Jul 2007 17:15:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5TFL-0006dY-Gy; Mon, 02 Jul 2007 17:15:47 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5TFL-00020n-Af; Mon, 02 Jul 2007 17:15:47 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 367BE2AC6B; Mon, 2 Jul 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5TEb-0002wG-W6; Mon, 02 Jul 2007 17:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 02 Jul 2007 17:15:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc4366-bis-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org --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 : Transport Layer Security (TLS) Extensions: Extension Definitions Author(s) : D. Eastlake 3rd Filename : draft-ietf-tls-rfc4366-bis-00.txt Pages : 22 Date : 2007-7-2 This document provides documentation for existing specific TLS extensions. It is a companion document for the TLS 1.2 specification, draft-ietf-tls-rfc4346-bis-03.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-rfc4366-bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-rfc4366-bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-2163328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc4366-bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc4366-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-2163328.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Mon Jul 02 17:53:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Tq5-0001TF-2I; Mon, 02 Jul 2007 17:53:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Tq4-0001TA-6E for tls@ietf.org; Mon, 02 Jul 2007 17:53:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Tpi-0002pU-ML for tls@ietf.org; Mon, 02 Jul 2007 17:53:44 -0400 Received: from [10.20.30.106] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l62LrKNZ097329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 14:53:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 2 Jul 2007 14:52:53 -0700 To: tls@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Donald Eastlake 3rd Subject: [TLS] Content of draft-ietf-tls-rfc4366-bis-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org At 5:15 PM -0400 7/2/07, Internet-Drafts@ietf.org wrote: >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 : Transport Layer Security (TLS) Extensions: >Extension Definitions > Author(s) : D. Eastlake 3rd > Filename : draft-ietf-tls-rfc4366-bis-00.txt > Pages : 22 > Date : 2007-7-2 > > This document provides documentation for existing specific TLS > extensions. It is a companion document for the TLS 1.2 specification, > draft-ietf-tls-rfc4346-bis-03.txt. Given last week's discussion on this list about clarifying 4366 with respect to IDNs, I would hope that this document could be more than a "make it sound right for TLS 1.2". If there are areas of 4366 that need clarifying (and there are), they should be made in this draft. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 03 02:07:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5bY5-0004p7-8j; Tue, 03 Jul 2007 02:07:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5bXy-0004Xs-Qf for tls@ietf.org; Tue, 03 Jul 2007 02:07:34 -0400 Received: from pcls5.std.com ([192.74.137.145] helo=TheWorld.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5bX7-0004Ao-7S for tls@ietf.org; Tue, 03 Jul 2007 02:07:34 -0400 Received: from owner.theworld.com (c-24-147-35-10.hsd1.ma.comcast.net [24.147.35.10]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l6366bEc025890; Tue, 3 Jul 2007 02:06:40 -0400 Message-Id: <200707030606.l6366bEc025890@TheWorld.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 Jul 2007 01:55:16 -0400 To: "Whyte, William" , "Eric Rescorla" , "Mike" From: Vin McLellan Subject: RE: [TLS] Signature Hash Agility In-Reply-To: References: <20070629160611.750F933C1A@delta.rtfm.com> <4686B8E0.2080709@pobox.com> <20070630210724.250E333C1A@delta.rtfm.com> <4686CE24.9050207@pobox.com> <20070630215839.27BB633C1A@delta.rtfm.com> <468726A2.8040909@pobox.com> <20070701051055.0C09E33C1A@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Burt Kaliski also has a 2002 paper, "On Hash=20 Function Firewalls in Signature Schemes," in=20 which he concluded that the best way to separate=20 different hash functions is in the infrastructure=20 itself (e.g., in certificates), rather than=20 within the signature scheme. It was published in=20 Topics in Cryptology =AD CT-RSA 2002, B. Preneel,=20 editor. This was volume 2271 of Lecture Notes in=20 Computer Science, Springer, 2002 RSA also offers the paper, and slides, at:=20 It's encouraging to see TLS thinking in the infrastructure direction. Suerte, _Vin PS. Hi William! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Eric Rescorla wrote: >> The DigestInfo ASN.1 structures need to be transmitted regardless >> of what the ordering rules are. They are there to prevent >> substitution attacks on the signature. At 09:52 AM 7/2/2007, William Whyte replied: >Burt Kaliski has a presentation about this=20 >approach, which he calls "Hash Function=20 >Firewalls". You can download the presentation in=20 >various formats from=20 >http://grouper.ieee.org/groups/1363/Research/Presentations.html=20 >(sorry no direct link -- bottom of the page). > >There are various downsides to these firewalls=20 >and it's not clear that they absolutely need to=20 >be included if a system's being designed from scratch. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 03 17:20:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5pnJ-0000zY-U7; Tue, 03 Jul 2007 17:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5pnI-0000z2-OR for tls@lists.ietf.org; Tue, 03 Jul 2007 17:20:20 -0400 Received: from smtp-out-68.livemail.co.uk ([213.171.216.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5pmI-0004xI-I5 for tls@lists.ietf.org; Tue, 03 Jul 2007 17:20:20 -0400 Received: from Postfix filter 42a77884ce2a0a03efc6bb50a6dcdb20 (smtp-out-58.livemail.co.uk [127.0.0.1]) by smtp-out-68.livemail.co.uk (Postfix) with SMTP id 9D2B7104CA for ; Tue, 3 Jul 2007 22:19:17 +0100 (BST) X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on spam-out-60.livemail.co.uk X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=RDNS_DYNAMIC autolearn=disabled version=3.2.0 Received: from YOUCA04DEATH (cpc2-cove8-0-0-cust493.brhm.cable.ntl.com [86.20.73.238]) by smtp-out-68.livemail.co.uk (Postfix) with ESMTP id C22A0463BCF for ; Tue, 3 Jul 2007 22:19:16 +0100 (BST) Message-ID: <000501c7bdb7$ce22a3f0$0300a8c0@YOUCA04DEATH> From: "Carl Young" To: Date: Tue, 3 Jul 2007 22:19:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Original-To: tls@lists.ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [TLS] TLS with SPNEGO X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Hi, I hope that this request is not O/T in this list, but I am looking for advice on utilising TLS along with SPNEGO using the current versions of TLS available on user platforms. My application currently utilizes TLS for mutual authentication as well as transport security but certificate/key management is proving to be an ongoing issue. The applications run as autonomous service processes which use the certificate authentication to give a reasonable level of 'comfort' that we know who we are talking to. In many cases my [particular] clients are not set up with any form of PKI, but they usually do have some form of single sign-on such as Kerberos, both in the Windows and Unix worlds. In most cases I would be communicating within the same realm/domain but in other cases, I have no other option than using certificate based authentication. I would like to amend the inter-node communications to utilize some form of negotiation. From my perspective utilizing some form of SPNEGO with TLS specified as a security mechanism seems to fit the bill, though I can not see that this has been used elsewhere (at least formally). I wouldn't be using the SPNEGO from within the O/S [for Windows], but providing an implementation derived from the Heimdal SPNEGO implementation. I would like to see if this is the 'right' way to go, or am I barking up the wrong tree. I appreciate any time you can give me, Regards, Carl Young _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From satomi@yahoo.co.jp Wed Jul 04 02:09:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5y38-0002kh-JV for TLS-ARCHIVE@LISTS.IETF.ORG; Wed, 04 Jul 2007 02:09:14 -0400 Received: from [60.18.52.95] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5y37-0002dM-8f for TLS-ARCHIVE@LISTS.IETF.ORG; Wed, 04 Jul 2007 02:09:14 -0400 Received: from dgp8 (unknown [72.4.135.66]) by smtp20 (Coremail) with SMTP id 5UQDb7PmPg3SU07K.1 for ; Fri, 04 Jul 2008 14:08:56 +0800 (CST) X-Originating-IP: [72.4.135.66] Subject: =?iso-2022-jp?B?GyRCTkkkKyRDJD8kaU8iTW0kLyRAJDUkJCJ2GyhCKCpeLV4p?= From: =?shift-jis?B?eWF1a28=?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7BD7B.54C59350" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C7BD7B.54C59350 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B7k:'(B10$B?tG/!":#$^$G2H;v!";E;v!"0i;y$K4hD%$C$F$-$^$7$?$,!"(B $B$3$3$iJU$j$G>/$7<+J,$K$4K+H~$r$"$2$F$b$$$$$+$J$H;W$C$F=q$-9~$_$7$F$$$^$9!#(B $B>!
=1B$B7k:'=1B(B10=1B$B?tG/!":#$^$G2H;v!";E;v!"0i;y$K4hD%$C$F$-$^$= 7$?$,!"=1B(B
=1B$B$3$3$iJU$j$G>/$7<+J,$K$4K+H~$r$"$2$F$b$$$$$+$J$H;W$C= $F=3Dq$-9~$_$7$F$$$^$9!#=1B(B
=1B$B>!=1B$B$=3D$l$rM}2r$7$F$/$l$kL@= $k$/M%$7$$CK@-!"NI$+$C$?$iO"Mm$/$@$5$$"v=1B(B(*^-^)=1B$B!!=1B(B
 
ID 15104 = =1B$B$G4i
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
=1B$B
hosono145yuko@yahoo.co.uk
------=_NextPart_000_0008_01C7BD7B.54C59350-- From tls-bounces@lists.ietf.org Wed Jul 04 07:52:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I63Ok-00039a-1C; Wed, 04 Jul 2007 07:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I63Oi-00039T-PN for tls@lists.ietf.org; Wed, 04 Jul 2007 07:51:52 -0400 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I63Od-00080Q-To for tls@lists.ietf.org; Wed, 04 Jul 2007 07:51:52 -0400 Received: from oaamta05sl.mx.bigpond.com ([61.9.204.42]) by omta05sl.mx.bigpond.com with ESMTP id <20070704115144.RDNY1743.omta05sl.mx.bigpond.com@oaamta05sl.mx.bigpond.com>; Wed, 4 Jul 2007 11:51:44 +0000 Received: from saxicola.cuneata.net ([61.9.204.42]) by oaamta05sl.mx.bigpond.com with ESMTP id <20070704115138.HJPS23230.oaamta05sl.mx.bigpond.com@saxicola.cuneata.net>; Wed, 4 Jul 2007 11:51:38 +0000 From: Brad Hards To: tls@lists.ietf.org Subject: Re: [TLS] Content of draft-ietf-tls-rfc4366-bis-00.txt Date: Wed, 4 Jul 2007 21:53:21 +1000 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707042153.24976.bradh@kdelabs.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Paul Hoffman , Donald Eastlake 3rd X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Tuesday 03 July 2007 07:52, Paul Hoffman wrote: > Given last week's discussion on this list about clarifying 4366 with > respect to IDNs, I would hope that this document could be more than a > "make it sound right for TLS 1.2". If there are areas of 4366 that > need clarifying (and there are), they should be made in this draft. There might also be a case for some of those features being made part of TLS 1.2 as core functionality (e.g. server MUST support) rather than being extensions/options. I think it is worth retaining the extension mechanism (and that perhaps should be described in rfc4346-bis rather than rfc4366-bis), but if we aren't all going to switch to STARTTLS, then Server Name Indication is probably worth incorporating into TLS 1.2, and maybe the fragment length and truncated HMAC should also be considered. Brad _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 06 11:48:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6q37-0005Lz-6H; Fri, 06 Jul 2007 11:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6q35-0005Aa-VQ for tls@lists.ietf.org; Fri, 06 Jul 2007 11:48:47 -0400 Received: from mail.ca.certicom.com ([38.113.160.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6q31-0005W4-Kl for tls@lists.ietf.org; Fri, 06 Jul 2007 11:48:47 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 5E4AB10027FEB for ; Fri, 6 Jul 2007 07:49:34 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sta7Yavv1-5G for ; Fri, 6 Jul 2007 07:49:32 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP for ; Fri, 6 Jul 2007 07:49:32 -0400 (EDT) To: tls@lists.ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Dana Zhao Date: Fri, 6 Jul 2007 11:45:01 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.2FP1|January 10, 2007) at 07/06/2007 11:44:44 AM, Serialize complete at 07/06/2007 11:44:44 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [TLS] Question for TLS1.2 AEAD cipher X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0134221707==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0134221707== Content-Type: multipart/alternative; boundary="=_alternative 0056DCEC85257310_=" This is a multipart message in MIME format. --=_alternative 0056DCEC85257310_= Content-Type: text/plain; charset="US-ASCII" Hi Tim and Eric, I have some questions in draft-ieft-tls-rfc4346-bis-03.txt, TLS version 1.2, 6.2.3.3 AEAD ciphers. 1. "opaque IV[SecurityParameters.iv_length]". Is IV encrypted? If so, how can the receiver use the IV to decrypt? I guess IV is in plain text, right? 2. The additional data for encryption and decryption should be the same. While we find that the additional data for encryption contains seq_num and the additional data for decryption does not contain seq_num. 3. IV length and Tag length. Is there standard IV length and Tag length? If not, when the receiver get the message, how does he know which part is IV and which part is aead_output? Also, the receiver needs to know the tag length for decryption. 4. On page 22, "Note that in many cases it is appropriate to use the partially implicit nonce technique of S 3.2.1 of AEAD", there is not such section 3.2.1 in Authenticated Encryption draft-mcgrew-auth-enc-00.txt. 5. How to choose the IV? Is IV of the following format? |--- client(server)_write_iv-----|------counter----------| Thank you very much! Dana --=_alternative 0056DCEC85257310_= Content-Type: text/html; charset="US-ASCII"
Hi Tim and Eric,

I have some questions in draft-ieft-tls-rfc4346-bis-03.txt, TLS version 1.2,  6.2.3.3 AEAD ciphers.

1. "opaque IV[SecurityParameters.iv_length]". Is IV encrypted? If so, how can the receiver use the IV to decrypt? I guess IV is in plain text, right?

2. The additional data for encryption and decryption should be the same. While we find that the additional data for encryption contains seq_num and the additional data for decryption does not contain seq_num.

3. IV length and Tag length. Is there standard IV length and Tag length? If not, when the receiver get the message, how does he know which part is IV and which part is aead_output? Also, the receiver needs to know the tag length for decryption.

4. On page 22, "Note that in many cases it is appropriate to use the partially implicit nonce technique of S 3.2.1 of AEAD", there is not such section 3.2.1 in Authenticated Encryption draft-mcgrew-auth-enc-00.txt.

5. How to choose the IV? Is IV of the following format?
   |--- client(server)_write_iv-----|------counter----------|

Thank you very much!

Dana --=_alternative 0056DCEC85257310_=-- --===============0134221707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0134221707==-- From unit_claimoffice@bellsouth.net Fri Jul 06 11:50:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6q4R-0008S2-PI; Fri, 06 Jul 2007 11:50:11 -0400 Received: from imf24aec.mail.bellsouth.net ([205.152.59.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6q4N-00066r-E9; Fri, 06 Jul 2007 11:50:11 -0400 Received: from ibm70aec.bellsouth.net ([192.168.16.253]) by imf24aec.mail.bellsouth.net with ESMTP id <20070706155006.DKBS4124.imf24aec.mail.bellsouth.net@ibm70aec.bellsouth.net>; Fri, 6 Jul 2007 11:50:06 -0400 Received: from mail.bellsouth.net ([192.168.16.253]) by ibm70aec.bellsouth.net with SMTP id <20070706155006.WHLF19567.ibm70aec.bellsouth.net@mail.bellsouth.net>; Fri, 6 Jul 2007 11:50:06 -0400 X-Mailer: Openwave WebEngine, version 2.8.16.1 (webedge20-101-1106-101-20040924) X-Originating-IP: [63.247.79.145] From: UK LOTTERY BOARD Reply-To: uknlclaims_promo@yahoo.co.uk Organization: UK LOTERY BOARD To: Subject: CONFIRM WINNING NIOTIFICATION....dear winner Date: Fri, 6 Jul 2007 11:50:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20070706155006.WHLF19567.ibm70aec.bellsouth.net@mail.bellsouth.net> X-Spam-Score: 1.8 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f k Lottery Board PROMOTIONS/PRIZE AWARD DEPARTMENT. 60 Merriman Road Blackheath London SE3 8RZ England. Dear Winner, CONSOLATION WINNER NOTICE We wish to congratulate and inform you on the selection of your email coupon number which was selected among the 6 lucky consolation prize winners Your email ID identified with coupon No. PBL2348974321 and was selected by our E-games Random Selection System (ERSS) with entries from the 50,000 different email addresses enrolled for the E-game.you have been awarded the sum of (£2,600,000)You are to contact the claims agent with the following details for the release of your winnings. Claims Requirements: 1.Name in full: 2.Home Address: 3.Age: 4.Occupation: 5.Phone Number: 6.Present Country: 7.Sex: Overseas Claims Unit United Kingdom Lottery Fiduciary Contact Person: Mr. Macdanny Cole Contact E-mail: uknlclaims_promo@yahoo.co.uk Regards, Mrs. Monical Walter (Group Coordinator) From tls-bounces@lists.ietf.org Sat Jul 07 17:44:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7I4H-0002FJ-4F; Sat, 07 Jul 2007 17:43:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7I4F-0002F5-UY for tls@ietf.org; Sat, 07 Jul 2007 17:43:51 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7I4B-0001G4-LC for tls@ietf.org; Sat, 07 Jul 2007 17:43:51 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id ADD3F33C1A; Sat, 7 Jul 2007 14:42:05 -0700 (PDT) Date: Sat, 07 Jul 2007 14:42:04 -0700 From: Eric Rescorla To: Bodo Moeller Subject: Re: [TLS] Issue #12: RSA/DSA/DH timing attacks In-Reply-To: <20070608111726.GA15643@tau.invalid> References: <20070603145002.85D3133C4B@delta.rtfm.com> <20070608111552.GA15118@tau.invalid> <20070608111726.GA15643@tau.invalid> 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: <20070707214205.ADD3F33C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org At Fri, 8 Jun 2007 13:17:26 +0200, Bodo Moeller wrote: > On Fri, Jun 08, 2007 at 01:15:52PM +0200, Bodo Moeller wrote: > > > Having said that, here's how you could try to add blinding to DSA > > exponentiations -- either base and exponent blinding or just exponent > > blinding: > > > > - Compute g^k as g'^k' where g' = g^m (m random) is a blinded > > base value, and where k' = m'*k mod q. (Just as with RSA, you > > could keep the blinding parameters for a number of cryptographic > > operations for better performance.) > > Er, k' = k/m' mod q, of course. (I.e., you need a mod-q inversion.) OK. I'm not qualified to evaluate this, and I don't think we want to put it directly in TLS. Is there something we can reference for this technique or are you OK with leaving this as-is? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 07 19:16:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7JVS-0005j2-NU; Sat, 07 Jul 2007 19:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7JVP-0005Te-PI for tls@lists.ietf.org; Sat, 07 Jul 2007 19:15:59 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7JVL-0005if-Fw for tls@lists.ietf.org; Sat, 07 Jul 2007 19:15:59 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 0AC0233C1A; Sat, 7 Jul 2007 16:14:13 -0700 (PDT) Date: Sat, 07 Jul 2007 16:14:13 -0700 From: Eric Rescorla To: Dana Zhao Subject: Re: [TLS] Question for TLS1.2 AEAD cipher In-Reply-To: References: 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: <20070707231414.0AC0233C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org At Fri, 6 Jul 2007 11:45:01 -0400, Dana Zhao wrote: > 1.2, 6.2.3.3 AEAD ciphers. > > 1. "opaque IV[SecurityParameters.iv_length]". Is IV encrypted? If so, how > can the receiver use the IV to decrypt? I guess IV is in plain text, > right? Yes. > 2. The additional data for encryption and decryption should be the same. > While we find that the additional data for encryption contains seq_num and > the additional data for decryption does not contain seq_num. I don't see that in the text. > 3. IV length and Tag length. Is there standard IV length and Tag length? > If not, when the receiver get the message, how does he know which part is > IV and which part is aead_output? Also, the receiver needs to know the tag > length for decryption. It's defined by the cipher suite. > 4. On page 22, "Note that in many cases it is appropriate to use the > partially implicit nonce technique of S 3.2.1 of AEAD", there is not such > section 3.2.1 in Authenticated Encryption draft-mcgrew-auth-enc-00.txt. You need version -02. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 07 19:28:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Jh8-0007jW-Te; Sat, 07 Jul 2007 19:28:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Jh7-0007jQ-Rf for tls@ietf.org; Sat, 07 Jul 2007 19:28:05 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7Jh3-0006SM-Iv for tls@ietf.org; Sat, 07 Jul 2007 19:28:05 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5500133C1A for ; Sat, 7 Jul 2007 16:26:20 -0700 (PDT) Date: Sat, 07 Jul 2007 16:26:20 -0700 From: Eric Rescorla To: tls@ietf.org Subject: Re: [TLS] Signature Hash Agility In-Reply-To: <20070629160611.750F933C1A@delta.rtfm.com> References: <20070629160611.750F933C1A@delta.rtfm.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: <20070707232620.5500133C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org At Fri, 29 Jun 2007 09:06:10 -0700, Eric Rescorla wrote: > > 4. DSA hash selection > I claim it must be deterministic from the DSA SubjectPublicKeyInfo what hash > algorithm it is to be used with. Otherwise you risk substitution attacks. So, where this item is at is that I think that for the OID dsa (1 2 840 10040 4 1), we need to require SHA-1 and that PKIX needs to require a new OID for dsaWithSHAXXX to go in the SPKI. I have a note in the draft, but it's not finished. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 07 19:46:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7JzI-0004Yx-96; Sat, 07 Jul 2007 19:46:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7JzH-0004Yr-5L for tls@ietf.org; Sat, 07 Jul 2007 19:46:51 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7Jz1-0007RZ-TE for tls@ietf.org; Sat, 07 Jul 2007 19:46:51 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 408E033C1A; Sat, 7 Jul 2007 16:43:58 -0700 (PDT) Date: Sat, 07 Jul 2007 16:43:57 -0700 From: Eric Rescorla To: Nelson B Bolyard Subject: Re: [TLS] Issue 16: Alert clarifications In-Reply-To: <466CB8EF.9080700@bolyard.com> References: <20070603145730.4507B33C4B@delta.rtfm.com> <20070607132918.4459D33C58@delta.rtfm.com> <4668CDF7.9030600@bolyard.com> <20070608083514.GA11066@tau.invalid> <466CB8EF.9080700@bolyard.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: <20070707234358.408E033C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org At Sun, 10 Jun 2007 19:52:31 -0700, Nelson B Bolyard wrote: > > Why not require that a fatal alert be sent any time that the connection > > is going to be torn down due to a protocol error of any kind? > > I still think that deserves an answer. As I said previously, I'm not comfortable with this without a full security analysis of all of the implications of every single thing that might go wrong, esp. as we have been burned by inappropriate alerts in the past. Since nobody has volunteered to do said analysis, the minimum safe thing is to simply require that the current fatal alerts be sent. I appreciate that you feel that it would make debugging easier to require an alert in every case, but, then, so would including the exact line of code on the local side that generated the failure, but I don't hear anyone proposing that, so I don't think this is the only consideration. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jul 08 10:52:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Y7n-0004FO-Tq; Sun, 08 Jul 2007 10:52:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Y7m-0004FJ-Tf for tls@ietf.org; Sun, 08 Jul 2007 10:52:34 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7Y7m-0005Et-Jw for tls@ietf.org; Sun, 08 Jul 2007 10:52:34 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 4C2B033C55 for ; Sun, 8 Jul 2007 07:50:51 -0700 (PDT) Date: Sun, 08 Jul 2007 07:50:51 -0700 From: Eric Rescorla To: tls@ietf.org 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: <20070708145051.4C2B033C55@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [TLS] draft-ietf-tls-rfc4346-04 available X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I just submitted draft-ietf-tls-rfc4346-04. Until it's in the repository, you can find it at: https://svn.resiprocate.org/rep/ietf-drafts/ekr/tls/tls.txt The changes are: - Added some guidance about checking DH groups and exponents. [Issues 15 and 43] - DigestInfo now MUST be NULL but must be accepted either way per discussion in Prague [Issue 22] - Improved versions of Bleichenbacher/Klima/Version number text for the EPMS (due to Eronen) [Issue 17] - Cleaned up SSLv2 backward compatibility text [Issue 25] - Improvements to signature hash agility text [Issue 41]. Still not completely fixed. - Changed cert_hash_types to signature hash types and indicated a preference order. The two open issues I know of are: 1. There is still no requirement that any termination of the connection be preceded by a fatal error. I indicated my reasoning in a message last night and I haven't seen consensus for this change, nor did I see any in the discussion in Prague. If there is a lot of objection here I would ask Pasi to do a strawpoll. 2. There's still a handwave about how to know what hash is to be used with a given signature algorithm. IMO it should be in the SPKI of the relevant cert for every algorithm but RSA-PKCS1-v15 and for backward compatibility, if the cert is bare dsa it should be SHA-1. This requires an indicator in the cert, however, so we need to at least talk to PKIX about it, hence the handwave. Also, I deliberately didn't talk about issues with cert types/algorithms not mentioned in this draft, i.e., PGP and ECC... Also, I'm waiting for some additional text from Pasi on implementation pitfalls. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 09 05:54:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7pwk-00023W-Fh; Mon, 09 Jul 2007 05:54:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7pwj-00023G-DO for tls@ietf.org; Mon, 09 Jul 2007 05:54:21 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7pwj-00020c-3o for tls@ietf.org; Mon, 09 Jul 2007 05:54:21 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 9 Jul 2007 02:53:25 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.726.0; Mon, 9 Jul 2007 02:53:25 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jul 2007 02:53:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jul 2007 02:52:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GSS-API TLS ID published Thread-Index: AcfCDuLqIYtsvpiiRuaUSBMzECJgRg== From: Larry Zhu To: X-OriginalArrivalTime: 09 Jul 2007 09:53:24.0825 (UTC) FILETIME=[FDE3E490:01C7C20E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Subject: [TLS] GSS-API TLS ID published X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0929066041==" Errors-To: tls-bounces@lists.ietf.org --===============0929066041== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C20E.E3B903AA" ------_=_NextPart_001_01C7C20E.E3B903AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have submitted the GSS-API TLS ID based on PSK as suggested in the previous IETF meetings. =20 http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt =20 please review to see if the comments have been addressed. =20 ------_=_NextPart_001_01C7C20E.E3B903AA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have submitted the GSS-API TLS ID based on PSK as suggested in the previous IETF meetings.

 

http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.t= xt

 

please review to see if the comments have been = addressed.

 

------_=_NextPart_001_01C7C20E.E3B903AA-- --===============0929066041== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0929066041==-- From tls-bounces@lists.ietf.org Mon Jul 09 11:41:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7vME-00010N-4F; Mon, 09 Jul 2007 11:41:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7vMB-000105-T8 for tls@lists.ietf.org; Mon, 09 Jul 2007 11:40:59 -0400 Received: from mail.ca.certicom.com ([38.113.160.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7vM7-0003Ak-HO for tls@lists.ietf.org; Mon, 09 Jul 2007 11:40:59 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id CAE1B10027FE6; Mon, 9 Jul 2007 07:41:50 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezTlPQ0edmuK; Mon, 9 Jul 2007 07:41:49 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP; Mon, 9 Jul 2007 07:41:49 -0400 (EDT) In-Reply-To: <20070707231414.0AC0233C1A@delta.rtfm.com> To: Eric Rescorla Subject: Re: [TLS] Question for TLS1.2 AEAD cipher MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Dana Zhao Date: Mon, 9 Jul 2007 11:37:15 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.2FP1|January 10, 2007) at 07/09/2007 11:36:55 AM, Serialize complete at 07/09/2007 11:36:55 AM X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============1984908905==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1984908905== Content-Type: multipart/alternative; boundary="=_alternative 0056270185257313_=" This is a multipart message in MIME format. --=_alternative 0056270185257313_= Content-Type: text/plain; charset="US-ASCII" Hi Eric, Thank you very much for your quick response. >> 2. The additional data for encryption and decryption should be the same. >> While we find that the additional data for encryption contains seq_num and >> the additional data for decryption does not contain seq_num. >I don't see that in the text. It is on page 23, draft-ietf-tls-rfc4346-bis-03.txt or draft-ietf-tls-rfc4346-bis-04.txt. additional_data = seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length; AEADEncrypted = AEAD-Encrypt(key, IV, plaintext, additional_data) TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, AEADEncrypted, TLSCiphertext.type + TLSCiphertext.version + TLSCiphertext.length); >> 3. IV length and Tag length. Is there standard IV length and Tag length? >> If not, when the receiver get the message, how does he know which part is >> IV and which part is aead_output? Also, the receiver needs to know the tag >> length for decryption. >It's defined by the cipher suite. For example, cipher suite "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", GCM allows Tag length from 8 to 16 bytes, IV length from 1 to 2^64 bytes(the recommended IV length is 12 bytes). What Tag length and IV length should we choose? The recommended length? Thank you. Dana --=_alternative 0056270185257313_= Content-Type: text/html; charset="US-ASCII"
Hi Eric,

Thank you very much for your quick response.




>> 2. The additional data for encryption and decryption should be the same.
>> While we find that the additional data for encryption contains seq_num and
>> the additional data for decryption does not contain seq_num.

>I don't see that in the text.

It is on page 23, draft-ietf-tls-rfc4346-bis-03.txt or draft-ietf-tls-rfc4346-bis-04.txt.

 additional_data = seq_num + TLSCompressed.type +
                       TLSCompressed.version + TLSCompressed.length;
 AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
                     additional_data)
 TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, AEADEncrypted,
                  TLSCiphertext.type + TLSCiphertext.version +
                  TLSCiphertext.length);


>> 3. IV length and Tag length. Is there standard IV length and Tag length?
>> If not, when the receiver get the message, how does he know which part is
>> IV and which part is aead_output? Also, the receiver needs to know the tag
>> length for decryption.

>It's defined by the cipher suite.

For example, cipher suite "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", GCM allows Tag length from 8 to 16 bytes, IV length from 1 to 2^64 bytes(the recommended IV length is 12 bytes). What Tag length and IV length should we choose? The recommended length?

Thank you.

Dana
--=_alternative 0056270185257313_=-- --===============1984908905== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1984908905==-- From tls-bounces@lists.ietf.org Mon Jul 09 15:15:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yhn-0000N4-DO; Mon, 09 Jul 2007 15:15:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yhf-0000EH-9n; Mon, 09 Jul 2007 15:15:23 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7yhf-0003B2-0s; Mon, 09 Jul 2007 15:15:23 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id D22EF2ACB9; Mon, 9 Jul 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7yhK-0001wS-Jj; Mon, 09 Jul 2007 15:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Jul 2007 15:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc4346-bis-04.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org --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 : The TLS Protocol Version 1.2 Author(s) : T. Dierks, E. Rescorla Filename : draft-ietf-tls-rfc4346-bis-04.txt Pages : 96 Date : 2007-7-9 This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-rfc4346-bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-rfc4346-bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-9145515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc4346-bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc4346-bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-9145515.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Tue Jul 10 09:20:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8FdI-0003eN-SC; Tue, 10 Jul 2007 09:20:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8FdH-0003eD-PO for tls@ietf.org; Tue, 10 Jul 2007 09:19:59 -0400 Received: from moutng.kundenserver.de ([212.227.126.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Fd2-00056e-Br for tls@ietf.org; Tue, 10 Jul 2007 09:19:59 -0400 Received: from [134.147.40.246] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1I8Fch2AaD-0003vr; Tue, 10 Jul 2007 15:19:24 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 206721A344; Tue, 10 Jul 2007 15:19:23 +0200 (CEST) Date: Tue, 10 Jul 2007 15:19:23 +0200 From: Bodo Moeller To: Eric Rescorla Subject: Re: [TLS] Issue #12: RSA/DSA/DH timing attacks Message-ID: <20070710131923.GA10336@tau.invalid> References: <20070603145002.85D3133C4B@delta.rtfm.com> <20070608111552.GA15118@tau.invalid> <20070608111726.GA15643@tau.invalid> <20070707214205.ADD3F33C1A@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070707214205.ADD3F33C1A@delta.rtfm.com> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX19OLDxnevqWW+CcSRbRH3dHZMCVGiLmQSCTReJ sXfIfjFAnqYtxebmKqtftyp9TYsmJGv64oqWQ9LT/dQNAgbtzP T26RJHExMz67nAntA6n6w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Sat, Jul 07, 2007 at 02:42:04PM -0700, Eric Rescorla wrote: >> On Fri, Jun 08, 2007 at 01:15:52PM +0200, Bodo Moeller wrote: >>> Having said that, here's how you could try to add blinding to DSA >>> exponentiations -- either base and exponent blinding or just exponent >>> blinding: >>> >>> - Compute g^k as g'^k' where g' = g^m (m random) is a blinded >>> base value, and where k' = m'*k mod q. (Just as with RSA, you >>> could keep the blinding parameters for a number of cryptographic >>> operations for better performance.) >> Er, k' = k/m' mod q, of course. (I.e., you need a mod-q inversion.) > OK. I'm not qualified to evaluate this, and I don't think we want to > put it directly in TLS. Is there something we can reference for this > technique or are you OK with leaving this as-is? I think just including a general recommendation to do something about timing attacks is appropriate for the TLS specification. This could go into the Security Considerations section. There's a "MUST" for RSA in the current draft ("MUST use RSA blinding or some other anti-timing technique"), but this appears just in the section on RSA-encrypted premaster secrets, which actually is a situation quite different from that for DSA. With an encrypted premaster secret, an adversary gets to pick the input to the RSA exponentiation; for signatures, the adversary can't get that much control. DSA is similar in use to RSA *signatures*, for which the current draft does not demand blinding. The Security Considerations should mention timing-attack issues for all kinds of public-key cryptography, but they shouldn't provide detailed recommendations on how to handle these, since this is still a research topic. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From sweep_stakes@bellsouth.net Tue Jul 10 17:37:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8NOI-0001kP-3S; Tue, 10 Jul 2007 17:37:02 -0400 Received: from imf20aec.mail.bellsouth.net ([205.152.59.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8NOE-0004oa-Ps; Tue, 10 Jul 2007 17:37:02 -0400 Received: from ibm62aec.bellsouth.net ([192.168.16.253]) by imf20aec.mail.bellsouth.net with ESMTP id <20070710213657.GNPF21721.imf20aec.mail.bellsouth.net@ibm62aec.bellsouth.net>; Tue, 10 Jul 2007 17:36:57 -0400 Received: from mail.bellsouth.net ([192.168.16.253]) by ibm62aec.bellsouth.net with SMTP id <20070710213656.BIDZ20509.ibm62aec.bellsouth.net@mail.bellsouth.net>; Tue, 10 Jul 2007 17:36:56 -0400 X-Mailer: Openwave WebEngine, version 2.8.16.1 (webedge20-101-1106-101-20040924) X-Originating-IP: [63.247.79.145] From: UK LOTTERY BOARD Reply-To: uknlclaims_promo@yahoo.co.uk Organization: UK LOTTERY BOARD To: Subject: CONGRATULATION..........dear winner Date: Tue, 10 Jul 2007 17:36:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20070710213656.BIDZ20509.ibm62aec.bellsouth.net@mail.bellsouth.net> X-Spam-Score: 1.8 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Dear Winner, CONSOLATION WINNER NOTICE We wish to congratulate and inform you on the selection of your email coupon number which was selected among the 6 lucky consolation prize winners Your email ID identified with coupon No. PBL2348974321 and was selected by our E-games Random Selection System (ERSS) with entries from the 50,000 different email addresses enrolled for the E-game.you have been awarded the sum of (£2,600,000)You are to contact the claims agent with the following details for the release of your winnings. Claims Requirements: 1.Name in full: 2.Home Address: 3.Age: 4.Occupation: 5.Phone Number: 6.Present Country: 7.Sex: Overseas Claims Unit United Kingdom Lottery Fiduciary Contact Person: Mr. Macdanny Cole Contact E-mail: uknlclaims_promo@yahoo.co.uk Regards, Mrs. Monical Walter (Group Coordinator) From winner2007@bellsouth.net Tue Jul 10 21:26:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8QyN-0000LV-EW; Tue, 10 Jul 2007 21:26:31 -0400 Received: from imf16aec.mail.bellsouth.net ([205.152.59.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8QyJ-000165-5I; Tue, 10 Jul 2007 21:26:31 -0400 Received: from ibm56aec.bellsouth.net ([192.168.16.253]) by imf16aec.mail.bellsouth.net with ESMTP id <20070711012626.KTOC8981.imf16aec.mail.bellsouth.net@ibm56aec.bellsouth.net>; Tue, 10 Jul 2007 21:26:26 -0400 Received: from mail.bellsouth.net ([192.168.16.253]) by ibm56aec.bellsouth.net with SMTP id <20070711012626.XVZI12983.ibm56aec.bellsouth.net@mail.bellsouth.net>; Tue, 10 Jul 2007 21:26:26 -0400 X-Mailer: Openwave WebEngine, version 2.8.16.1 (webedge20-101-1106-101-20040924) X-Priority: 1 X-Originating-IP: [220.232.137.232] From: Online Notification Organization: Online Notification To: Subject: You Won!!! Date: Tue, 10 Jul 2007 21:26:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20070711012626.XVZI12983.ibm56aec.bellsouth.net@mail.bellsouth.net> X-Spam-Score: 1.3 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b THE COCA COLA COMPANY PROMOTION PRIZE AWARD DEPTCOCA COLA AVENUE STAMFORD BRIDGE LONDON. SW1V 3DW UNITED KINGDOM THE COCA COLA COMPANY OFFICIAL PRIZE NOTIFICATION We are pleased to inform you of the result of the just concluded annual final draws held on the (23th June 2007) by Coca-Cola in conjunction with the British American Tobacco Worldwide Promotion, your email was among the 20 Lucky winners who won £1,000,000.00 each on the THE COCA COLA COMPANY PROMOTION. However the results were released on the 25th June 2007 and your email was attached to ticket number (4FKAW2006) and ballot number (BT 28142006/22) The online draws was conducted by a random selection of email addresses from an exclusive list of 29,031 E-mail addresses of individuals and corporate bodies picked by an advanced automated random computer search from the internet. However, no tickets were sold but all email addresses were assigned to different ticket numbers for representation and privacy. In other to claim your £1,000,000.00 prize winning, which has been deposited in a designated bank? However, you will have to fill the form below and send it to the Promotion manager of THE COCA COLA COMPANY for verification and then you will be directed to the courier company where a cheque of £1,000,000.00 has already been deposited in your favor. Name: Mr. Kenneth Smith, Phone: +44-703-189-8008 Fax: +44-707-505-5400 E MAIL: onlinepromo.cocacolalottery@yahoo.co.uk To avoid unnecessary delays and complications, you are to contact Mr. Kenneth Smith with followings details below: NAME:................................... AGE:..................................... SEX:..................................... ADDRESS:.............................. EMAIL:.................................. PHONE:................................. OCCUPATION:........................ COMPANY:............................. NATIONALITY:........................ COUNTRY:............................. Congratulations, once more from all members and staffs of this program. Thank you for being part of our promotional lottery program. TEAM. Sincerely, Mrs. Alice Caldwell. (Zonal Coordinator) SEND YOUR EMAIL TO: onlinepromo.cocacolalottery@yahoo.co.uk From salam_asinthe64@hotmail.fr Thu Jul 12 04:45:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8uIu-0005Ja-J1; Thu, 12 Jul 2007 04:45:40 -0400 Received: from bay0-omc2-s13.bay0.hotmail.com ([65.54.246.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8uIq-0003Tl-6A; Thu, 12 Jul 2007 04:45:40 -0400 Received: from BLU104-W18 ([10.6.55.53]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 12 Jul 2007 01:45:35 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c41d6266-7a58-4faf-ae9a-5ae01e5ffe10_" X-Originating-IP: [196.28.242.148] Reply-To: From: salam asinthe Subject: ATTENTION PLEASE! Date: Thu, 12 Jul 2007 08:45:32 +0000 Importance: Normal MIME-Version: 1.0 Bcc: X-OriginalArrivalTime: 12 Jul 2007 08:45:35.0683 (UTC) FILETIME=[03BB5930:01C7C461] X-Spam-Score: 4.4 (++++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f --_c41d6266-7a58-4faf-ae9a-5ae01e5ffe10_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FROM MR. ASINTHE SALAM. ATTENTION PLEASE! =20 I GOT YOUR CONTACT OVER THE INTERNET AS A TRUSTWORTHY AND RELIABLE PERSON.P= LEASE PAY ATTENTION AND UNDERSTAND MY REASON OF CONTACTING YOU TODAY THROUG= H THIS EMAIL. MY NAME IS MR.ASINTHE SALAM BILL AND EXCHANGEMANAGER,FOREIGN = REMITTANCE DEPT B.O.A BANK OF AFRICA HERE IN BURKINA FASO . =20 I AM THE ACCOUNT OFFICER TO A FOREIGN CUSTOMER,LATE MR. MORRIS THOMPSON ,AN= AMERICAN WHO UNFORTUNATELY LOST HIS LIFE IN THE PLANE CRASH OF ALASKA AIRL= INES FLIGHT 261, WHICH CRASHED ON JANUARY 31 2000. YOU MAY READ MORE ABOUT = THE CRASH ON VISITING THIS C.N.N NEWSINTERNET WEBSITE: =20 www.cnn.com/2000/US/02/01/alaska.airlines.list IN THIS REGARDS,I NEED YOUR ASSISTANCE TO APPLY THE URGENT RELEASE/AND TRAN= SFER OF THE DEPOSITED FUNDS LUMP OF $15.500,000 USD TO OUR BANK AS THE NEXT= (KIN) TO THE DECEASED PERSON. =20 I WANT SAY TO YOU THAT UPON SUCCESSFUL CONCLUSION OF THIS BUSINESS RELATION= SHIP 30% OF THE TOTAL SUM WILL BE OFFERED TO YOU AS YOU SHARE TO ACCEPT MY = PROPOSAL IN A GOOD FAITH IN TRANSFERRING THE SAID FUNDS. =20 FURTHER,REPLY ME IF THIS PROPOSAL IS ACCEPTABLE TO YOU SO THAT I CAN GIVE Y= OU MORE DETAILS ON HOW WE COULD COMMENCE.JUST BEAR IN MIND THAT MY INTENT I= S PURE,real and not gimmick. =20 I WAIT FOR YOUR URGENT RESPONDS. =20 YOURS FAITHFULLY,MR.ASINTHE SALAM _________________________________________________________________ Play free games, earn tickets, get cool prizes! Join Live Search Club.=A0 http://club.live.com/home.aspx?icid=3DCLUB_wlmailtextlink= --_c41d6266-7a58-4faf-ae9a-5ae01e5ffe10_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
FROM MR. ASINTHE SALAM.
       = ;            &n= bsp;            = ;            &n= bsp;  ATTENTION PLEASE!
 
I GOT YOUR CONTACT OVER THE INTERNET AS A= TRUSTWORTHY AND RELIABLE PERSON.PLEASE PAY ATTENTION AND UNDERSTAND MY REA= SON OF CONTACTING YOU TODAY THROUGH THIS EMAIL. MY NAME IS MR.ASINTHE SALAM= BILL AND EXCHANGE
MANAGER,FOREIGN REMITTANCE DEPT B.O.A BANK OF AFRICA = HERE IN BURKINA FASO .
 
I AM THE ACCOUNT OFFICER TO A FOREIGN CUS= TOMER,LATE MR. MORRIS THOMPSON ,AN AMERICAN WHO UNFORTUNATELY LOST HIS LIFE= IN THE PLANE CRASH OF ALASKA AIRLINES FLIGHT 261, WHICH CRASHED ON JANUARY= 31 2000. YOU MAY READ MORE ABOUT THE CRASH ON VISITING THIS C.N.N NEWS
= INTERNET WEBSITE:
 
IN THIS REGARDS,I NEED YOUR ASSISTANCE TO= APPLY THE URGENT RELEASE/AND TRANSFER OF THE DEPOSITED FUNDS LUMP OF $15.5= 00,000 USD TO OUR BANK AS THE NEXT (KIN) TO THE DECEASED PERSON.
 
I WANT SAY TO YOU THAT UPON SUCCESSFUL CO= NCLUSION OF THIS BUSINESS RELATIONSHIP 30% OF THE TOTAL SUM WILL BE OFFERED= TO YOU AS YOU SHARE TO ACCEPT MY PROPOSAL IN A GOOD FAITH IN TRANSFERRING = THE SAID FUNDS.
 
FURTHER,REPLY ME IF THIS PROPOSAL IS ACCE= PTABLE TO YOU SO THAT I CAN GIVE YOU MORE DETAILS ON HOW WE COULD COMMENCE.= JUST BEAR IN MIND THAT MY INTENT IS PURE,real and not gimmick.
 
I WAIT FOR YOUR URGENT RESPONDS.
 
YOURS FAITHFULLY,
MR.ASINTHE SALAM


Live Earth is coming.=A0 Learn more about the hott= est summer event - only on MSN. Check it out! = --_c41d6266-7a58-4faf-ae9a-5ae01e5ffe10_-- From info_08@bellsouth.net Thu Jul 12 18:57:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I97b8-0006Ea-I2; Thu, 12 Jul 2007 18:57:22 -0400 Received: from imf20aec.mail.bellsouth.net ([205.152.59.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I97b4-0000N8-7T; Thu, 12 Jul 2007 18:57:22 -0400 Received: from ibm64aec.bellsouth.net ([192.168.16.253]) by imf20aec.mail.bellsouth.net with ESMTP id <20070712225717.LAMC25478.imf20aec.mail.bellsouth.net@ibm64aec.bellsouth.net>; Thu, 12 Jul 2007 18:57:17 -0400 Received: from mail.bellsouth.net ([192.168.16.253]) by ibm64aec.bellsouth.net with SMTP id <20070712225717.LFBN18676.ibm64aec.bellsouth.net@mail.bellsouth.net>; Thu, 12 Jul 2007 18:57:17 -0400 X-Mailer: Openwave WebEngine, version 2.8.16.1 (webedge20-101-1106-101-20040924) X-Originating-IP: [198.145.182.24] From: LOTTERY WINNER Organization: LOTTERY WINNER To: Subject: Congratulations...Your Email Has Made You A Winner Date: Thu, 12 Jul 2007 18:57:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20070712225717.LFBN18676.ibm64aec.bellsouth.net@mail.bellsouth.net> X-Spam-Score: 2.3 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 THE COCA COLA COMPANY PROMOTION PRIZE AWARD DEPTCOCA COLA AVENUE STAMFORD BRIDGE LONDON. SW1V 3DW UNITED KINGDOM THE COCA COLA COMPANY OFFICIAL PRIZE NOTIFICATION We are pleased to inform you of the result of the just concluded annual final draws held on the (23th June 2007) by Coca-Cola in conjunction with the British American Tobacco Worldwide Promotion, your email was among the 20 Lucky winners who won £1,000,000.00 each on the THE COCA COLA COMPANY PROMOTION. However the results were released on the 25th June 2007 and your email was attached to ticket number (4FKAW2006) and ballot number (BT 28142006/22) The online draws was conducted by a random selection of email addresses from an exclusive list of 29,031 E-mail addresses of individuals and corporate bodies picked by an advanced automated random computer search from the internet. However, no tickets were sold but all email addresses were assigned to different ticket numbers for representation and privacy. In other to claim your £1,000,000.00 prize winning, which has been deposited in a designated bank? However, you will have to fill the form below and send it to the Promotion manager of THE COCA COLA COMPANY for verification and then you will be directed to the courier company where a cheque of £1,000,000.00 has already been deposited in your favor. Name: Mr. Kenneth Smith, Phone: +44-703-189-8008 Fax: +44-707-505-5400 E MAIL: onlinepromo.cocacolalottery@yahoo.co.uk To avoid unnecessary delays and complications, you are to contact Mr. Kenneth Smith with followings details below: NAME:................................... AGE:..................................... SEX:..................................... ADDRESS:.............................. EMAIL:.................................. PHONE:................................. OCCUPATION:........................ COMPANY:............................. NATIONALITY:........................ COUNTRY:............................. Congratulations, once more from all members and staffs of this program. Thank you for being part of our promotional lottery program. TEAM. Sincerely, Mrs. Alice Caldwell. (Zonal Coordinator) SEND YOUR EMAIL TO:onlinepromo.cocacolalottery@yahoo.co.uk Good day, I am Mrs Danielle Cordeau a money lender i give out loan to all in need of help.Are you looking for money to pay bills?I want you to know that i can help you with loan and i will be glad to offer you a loan. I give out home loans Car loans Mortgage loans Business Loans International Loans Personal Loans BORROWERS INFORMATION Your names ................................ Your country............................... Your address ................ Your Age............................... Your Fax Number................... Your occupation.......................... Your marital status ...................... Current Status at place of work......... Sex................................... Phone number.............................. Monthly Income............................... Amount Needed........................... Any interested applicant should please respond to my private e.mail address:danielleloans@hotmail.com Thanks. Mrs Danielle Cordeau From info_08@bellsouth.net Thu Jul 12 19:05:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I97iu-0005aL-W2; Thu, 12 Jul 2007 19:05:24 -0400 Received: from imf20aec.mail.bellsouth.net ([205.152.59.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I97iq-0000V9-Lq; Thu, 12 Jul 2007 19:05:24 -0400 Received: from ibm64aec.bellsouth.net ([192.168.16.253]) by imf20aec.mail.bellsouth.net with ESMTP id <20070712230519.NDPK25478.imf20aec.mail.bellsouth.net@ibm64aec.bellsouth.net>; Thu, 12 Jul 2007 19:05:19 -0400 Received: from mail.bellsouth.net ([192.168.16.253]) by ibm64aec.bellsouth.net with SMTP id <20070712230519.LIDH18676.ibm64aec.bellsouth.net@mail.bellsouth.net>; Thu, 12 Jul 2007 19:05:19 -0400 X-Mailer: Openwave WebEngine, version 2.8.16.1 (webedge20-101-1106-101-20040924) X-Originating-IP: [198.145.182.24] From: LOTTERY WINNER Organization: LOTTERY WINNER To: Subject: Congratulations...Your Email Has Made You A Winner Date: Thu, 12 Jul 2007 19:05:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20070712230519.LIDH18676.ibm64aec.bellsouth.net@mail.bellsouth.net> X-Spam-Score: 2.3 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 THE COCA COLA COMPANY PROMOTION PRIZE AWARD DEPTCOCA COLA AVENUE STAMFORD BRIDGE LONDON. SW1V 3DW UNITED KINGDOM THE COCA COLA COMPANY OFFICIAL PRIZE NOTIFICATION We are pleased to inform you of the result of the just concluded annual final draws held on the (23th June 2007) by Coca-Cola in conjunction with the British American Tobacco Worldwide Promotion, your email was among the 20 Lucky winners who won £1,000,000.00 each on the THE COCA COLA COMPANY PROMOTION. However the results were released on the 25th June 2007 and your email was attached to ticket number (4FKAW2006) and ballot number (BT 28142006/22) The online draws was conducted by a random selection of email addresses from an exclusive list of 29,031 E-mail addresses of individuals and corporate bodies picked by an advanced automated random computer search from the internet. However, no tickets were sold but all email addresses were assigned to different ticket numbers for representation and privacy. In other to claim your £1,000,000.00 prize winning, which has been deposited in a designated bank? However, you will have to fill the form below and send it to the Promotion manager of THE COCA COLA COMPANY for verification and then you will be directed to the courier company where a cheque of £1,000,000.00 has already been deposited in your favor. Name: Mr. Kenneth Smith, Phone: +44-703-189-8008 Fax: +44-707-505-5400 E MAIL: onlinepromo.cocacolalottery@yahoo.co.uk To avoid unnecessary delays and complications, you are to contact Mr. Kenneth Smith with followings details below: NAME:................................... AGE:..................................... SEX:..................................... ADDRESS:.............................. EMAIL:.................................. PHONE:................................. OCCUPATION:........................ COMPANY:............................. NATIONALITY:........................ COUNTRY:............................. Congratulations, once more from all members and staffs of this program. Thank you for being part of our promotional lottery program. TEAM. Sincerely, Mrs. Alice Caldwell. (Zonal Coordinator) SEND YOUR EMAIL TO:onlinepromo.cocacolalottery@yahoo.co.uk Good day, I am Mrs Danielle Cordeau a money lender i give out loan to all in need of help.Are you looking for money to pay bills?I want you to know that i can help you with loan and i will be glad to offer you a loan. I give out home loans Car loans Mortgage loans Business Loans International Loans Personal Loans BORROWERS INFORMATION Your names ................................ Your country............................... Your address ................ Your Age............................... Your Fax Number................... Your occupation.......................... Your marital status ...................... Current Status at place of work......... Sex................................... Phone number.............................. Monthly Income............................... Amount Needed........................... Any interested applicant should please respond to my private e.mail address:danielleloans@hotmail.com Thanks. Mrs Danielle Cordeau From tls-bounces@lists.ietf.org Fri Jul 13 07:47:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9JcZ-0006OR-Ti; Fri, 13 Jul 2007 07:47:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9JcY-0006Nx-Fz for tls@lists.ietf.org; Fri, 13 Jul 2007 07:47:38 -0400 Received: from email.falcontrol.com ([91.112.5.62] helo=linux.futureware.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9JcU-0004D5-5f for tls@lists.ietf.org; Fri, 13 Jul 2007 07:47:38 -0400 Received: by linux.futureware.at (Postfix, from userid 1000) id 052857E3E0; Fri, 13 Jul 2007 13:47:31 +0200 (CEST) From: Philipp =?iso-8859-1?q?G=FChring?= Organization: CAcert.org To: tls@lists.ietf.org Date: Fri, 13 Jul 2007 13:47:30 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707131347.31415.philipp@cacert.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [TLS] Client Certificate Protection X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Hi, Are there any plans to improve the protection of the client certificates in= =20 the TLS handshake against eavesdropping?=20 I believe that the client certificate should be encrypted in the TLS handsh= ake=20 to prevent identity theft. I heard rumors that it should be possible to encrypt the client certificate= in=20 the TLS Handhake, but I couldn=B4t find any hints in the specification.=20 Is it possible to package the Certificate message into a Encryption message? Some people are already tunneling a client-certificate TLS session inside a= n=20 anonymous TLS session to prevent plaintext client-certificate transport, bu= t=20 I don=B4t like that workaround ... Are there any good reasons for the client certificate to go unencrypted? Best regards, Philipp G=FChring PS: I couldn=B4t find any discussion about this topic on the TLS mailinglis= t=20 archive. If I overlooked it, please point me in the right direction. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 13 09:35:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9LJ0-0006Tf-SS; Fri, 13 Jul 2007 09:35:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9LIz-0006Ta-IX for tls@lists.ietf.org; Fri, 13 Jul 2007 09:35:33 -0400 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9LIv-0007WY-24 for tls@lists.ietf.org; Fri, 13 Jul 2007 09:35:33 -0400 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id PAA475344 ; Fri, 13 Jul 2007 15:33:21 +0100 Message-ID: <46977F88.8090709@isima.fr> Date: Fri, 13 Jul 2007 15:35:04 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Philipp_G=FChring?= Subject: Re: [TLS] Client Certificate Protection References: <200707131347.31415.philipp@cacert.org> In-Reply-To: <200707131347.31415.philipp@cacert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sp.isima.fr id PAA475344 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Philipp G=FChring a =E9crit : > Hi, > > Are there any plans to improve the protection of the client certificate= s in=20 > the TLS handshake against eavesdropping?=20 > I believe that the client certificate should be encrypted in the TLS ha= ndshake=20 > to prevent identity theft. > I heard rumors that it should be possible to encrypt the client certifi= cate in=20 > the TLS Handhake, but I couldn=B4t find any hints in the specification.= =20 > Is it possible to package the Certificate message into a Encryption mes= sage? > Some people are already tunneling a client-certificate TLS session insi= de an=20 > anonymous TLS session to prevent plaintext client-certificate transport= , but=20 > I don=B4t like that workaround ... > Are there any good reasons for the client certificate to go unencrypted= ? > > Best regards, > Philipp G=FChring > PS: I couldn=B4t find any discussion about this topic on the TLS mailin= glist=20 > archive. If I overlooked it, please point me in the right direction. > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > > =20 Hi Philipp, As you cited in your mail, you can run a TLS handshake with only server=20 authentication and then rehandshake with mutual authentication. I already submitted another proposition available at=20 http://www.ietf.org/internet-drafts/draft-hajjeh-tls-identity-protection-= 01.txt,=20 and we had a discussion on this topic; available at =20 http://www.imc.org/ietf-tls/mail-archive/msg05740.html Best regards, --=20 Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 13 11:00:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MdU-0005rY-BE; Fri, 13 Jul 2007 11:00:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MdR-0005jp-Av for tls@lists.ietf.org; Fri, 13 Jul 2007 11:00:45 -0400 Received: from ccaix.jsums.edu ([143.132.8.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9MdM-0002Ez-Ti for tls@lists.ietf.org; Fri, 13 Jul 2007 11:00:45 -0400 Received: from webmail.jsums.edu ([143.132.8.100]) by ccaix.jsums.edu (8.13.1/8.13.1) with ESMTP id l6DF0dtZ019176; Fri, 13 Jul 2007 10:00:39 -0500 Received: from 172.132.188.100 (SquirrelMail authenticated user nmeghanathan) by webmail.jsums.edu with HTTP; Fri, 13 Jul 2007 10:00:39 -0500 (CDT) Message-ID: <1452.172.132.188.100.1184338839.squirrel@webmail.jsums.edu> Date: Fri, 13 Jul 2007 10:00:39 -0500 (CDT) From: nmeghanathan@jsums.edu To: tls@lists.ietf.org User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: iaria.announce@gmail.com Subject: [TLS] CFP: ICNS 2008, The Fourth International Conference on Networking and Services X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Please apologize for any cross-postings --------------------------------------- Invitation: Please consider to contribute and distribute to the appropriate groups the following CALL FOR PAPERS, TUTORIALS, PANELS The Fourth International Conference on Networking and Services ICNS 2008 March 16-21, 2008 - Gosier, Guadeloupe Site: http://www.iaria.org/conferences2008/ICNS08.html Submit a paper: http://www.iaria.org/conferences2008/SubmitICNS08.html Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be invited for specialized journals. Important deadlines: Submission deadline: October 5, 2007 Notification of acceptance: November 15, 2007 Registration/camera ready: December 5, 2007 ICNS 2008 Tracks (details in the CfP on site) * ENCOT: Emerging Network Communications and Technologies * COMAN: Network Control and Management * SERVI: Multi-technology service deployment and assurance * NGNUS: Next Generation Networks and Ubiquitous Services * MPQSI: Multi Provider QoS/SLA Internetworking * GRIDNS: Grid Networks and Services * EDNA: Emergency Services and Disaster Recovery of Networks and Applications * IPv6DFI: Deploying the Future Infrastructure * IPDy: Internet Packet Dynamics * GOBS: GRID over Optical Burst Switching Networks ====================== IARIA Publicity Board ====================== _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 13 12:19:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Nrc-0007XB-71; Fri, 13 Jul 2007 12:19:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Nra-0007X4-WF for tls@lists.ietf.org; Fri, 13 Jul 2007 12:19:27 -0400 Received: from mail.gi-de.com ([193.108.184.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9NrW-0005SX-I6 for tls@lists.ietf.org; Fri, 13 Jul 2007 12:19:26 -0400 Received: from notessmtp1.domino.intern [10.4.4.49] by mail.gi-de.com id 8VYTAZL9 outgoing id 8VYTAZL9; 13 Jul 2007 18:19:21 +0200 To: tls@lists.ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Axel.Heider@gi-de.com Date: Fri, 13 Jul 2007 18:19:20 +0200 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 7.0.2|September 26, 2006) at 13.07.2007 18:19:20, Serialize complete at 13.07.2007 18:19:20 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [TLS] Support for TLS extensions X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Hi, does anybody on this list know, which servers and browser support TLS extensions, especially max_fragment_size? OpenSSL does not support them in the current version 0.98 (but upcomming 0.99 may have it when it's released). And Firefox 2.0.0.4 does not care about the record length, too. regards, Axel _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 13 19:47:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9UrM-0001I8-29; Fri, 13 Jul 2007 19:47:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9UrL-0001Hm-6V for tls@ietf.org; Fri, 13 Jul 2007 19:47:39 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9UrH-0004wG-Md for tls@ietf.org; Fri, 13 Jul 2007 19:47:39 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 13 Jul 2007 16:47:34 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.726.0; Fri, 13 Jul 2007 16:46:31 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jul 2007 16:46:30 -0700 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 Jul 2007 16:46:12 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GSS based PSK-TLS Thread-Index: AcfFp/7J0qtkAaT3SLKZnxKACBA9zw== From: Larry Zhu To: X-OriginalArrivalTime: 13 Jul 2007 23:46:30.0319 (UTC) FILETIME=[0937FBF0:01C7C5A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Subject: [TLS] GSS based PSK-TLS X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org We would like to request for comments for the GSS based PSK-TLS ID: http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt We have few comments that came after the draft submission that we felt=20 it is important to bring up some of them to the list here.=20 Jeff Altman will make -03 available before ITTF69 that would merge the changes=20 so far. 1) Why the GSS handshake does not come before the hello message? Having the GSS handshake before the hello is not backward compatible=20 with the TLS protocols. 2) Why the GSS handshake does not come after the key exchange message? We do not want to pay for the cost of the DHE or RSA in this case.=20 The main motivation for us is to enable Kerberos to secure TLS connections.=20 Kerberos is a lot faster, and we intend to keep it that way. 3) why it is not an issue to have arbitrary number of GSS round trips? This has been raised previously.=20 The arguments that EKR made starting on 3/8/2007 on the old thread may not=20 apply given that we are doing the Kerberos AP-REQ and AP-REP in the hello=20 messages using TLS extensions, and the Kerberos shared key is them=20 imported to PSK-TLS.=20 We (Jeff, Stefan and I) would like to have folks to review the=20 new ID and see if your opinions have changed. We believe the revised ID has minimal impact to the TLS state machine. Also there are the handshake loop could be a stretch for mobile=20 devices that have limited computing capabilities or in situations=20 where the network latency is large such as satellite links.=20 To address that concern, we introduce a policy that limit the # of=20 GSS hand shake messages.=20 In addition, the TLS client does not choose a GSS mechanism that can=20 potentially have a large number of round-trips in the above circumstances.=20 The TLS client chooses which set of cipher suites to support as it does today,=20 and it can choose which GSS mechanism set is supported according to RFC4178. =20 4) client authentication The client and server authentication as defined in -02 need clarity.=20 The following text describes the mechanism.=20 The client MUST NOT include a gss_api TLS extension if there is no PSK ciphersuite [RFC4279] included in the cipher_suites field of the client hello message. Initially the client computes the gss_api TLS extention data by calling GSS_Init_sec_context() [RFC2743] to establish a security context. The TLS client MUST set the mutual_req_flag and identify the server by targ_name so that mutual authentication is performed in the course of context establishment. If the mutual authentication is not available on the established GSS- API context, the PSK key exchange described in Section 2 of [RFC4279] MUST NOT be selected, and the DHE_PSK or RSA_PSK key exchange MUST be negotiated instead in order to authenticate the server. =20 If the GSS-API mechanism in the gss_api TLS extension provides client authentication [RFC2743], the CertificateRequest, the client Certificate and the CertificateVerify handshake messages MUST NOT be present. This is illustrated in Appendix A. Client Server ClientHello(with AP-REQ) --------> ServerHello(with AP-REP) <-------- ServerHelloDone ClientKeyExchange [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <--------> Application Data Fig. 2. Kerberos FKA-TLS example message flow 5) what are the parameters to GSS PRF? The input parameters to GSS_Pseudo_random() to compute the shared scret value MUST be provided as follows: o The context is the handle to the GSS-API context established in the given session. o The prf_key is GSS_C_PRF_KEY_FULL. o The prf_in contains the UTF8 encoding of the string "GSS-API TLS PSK". o The desired_output_len is 64. In other words, the output keying mastering size is 64 in bytes. 6) how are the GSS mechanisms negotiated? This logic is encapsulated in GSS. SPNEGO as defined in RFC4178 can do it.=20 The concern is that such negotiation can be suboptimal when there are two=20 layers of negotiation, one in the TLS hello message, and the other in the=20 GSS layer. We believe such concern can be addressed by allowing additional=20 input to GSS negotiation to share the negotiation hint. That can be=20 accomplished, for example, by extending RFC4178. As long as the cipher suite decision is made in one round-trip that the=20 fact that the GSS OID options are carried in a GSS token instead of the=20 TLS cipher list does not result in a two-layer negotiation. -- Larry Zhu on behalf of Larry, Jeff and Stefan. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jul 15 23:56:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAHgQ-0003C2-LO; Sun, 15 Jul 2007 23:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAHgP-0003Br-DC for tls@lists.ietf.org; Sun, 15 Jul 2007 23:55:37 -0400 Received: from moe.its.auckland.ac.nz ([130.216.12.35] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAHgK-0005ID-Uz for tls@lists.ietf.org; Sun, 15 Jul 2007 23:55:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D396448046D; Mon, 16 Jul 2007 15:55:18 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxLnBdPMtO2O; Mon, 16 Jul 2007 15:55:18 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BC0A248046B; Mon, 16 Jul 2007 15:55:18 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 63773D14CFC; Mon, 16 Jul 2007 15:55:17 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1IAHg9-0000f4-00; Mon, 16 Jul 2007 15:55:21 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Axel.Heider@gi-de.com, tls@lists.ietf.org Subject: Re: [TLS] Support for TLS extensions In-Reply-To: Message-Id: Date: Mon, 16 Jul 2007 15:55:21 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Axel.Heider@gi-de.com writes: >does anybody on this list know, which servers and browser support TLS >extensions, especially max_fragment_size? My code has support in there for it, but since I've never found anything else that does it's currently commented out because I haven't been able to do any interop testing. (It's always interesting to look back on these desperately-needed facilities that are added to standards to find that no-one is actually using them once they're there :-). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 16 06:44:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAO3w-0000ri-HN; Mon, 16 Jul 2007 06:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAO3t-0000ra-BT for tls@lists.ietf.org; Mon, 16 Jul 2007 06:44:17 -0400 Received: from mail.ca.certicom.com ([38.113.160.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAO3o-0005PC-Tz for tls@lists.ietf.org; Mon, 16 Jul 2007 06:44:17 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 9CDB810027FE4; Mon, 16 Jul 2007 02:45:18 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axPmDTPPrs4M; Mon, 16 Jul 2007 02:45:17 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP; Mon, 16 Jul 2007 02:45:17 -0400 (EDT) In-Reply-To: To: Axel.Heider@gi-de.com Subject: Re: [TLS] Support for TLS extensions MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Mon, 16 Jul 2007 06:39:28 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.2FP1|January 10, 2007) at 07/16/2007 06:40:09 AM, Serialize complete at 07/16/2007 06:40:09 AM X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0671706540==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0671706540== Content-Type: multipart/alternative; boundary="=_alternative 003AE61B8525731A_=" This is a multipart message in MIME format. --=_alternative 003AE61B8525731A_= Content-Type: text/plain; charset="US-ASCII" We support the max_fragment_length extension in our SSL-C product. If you want to test interop I'll see if we can enable it on tls.secg.org The SSL-C product supports the following TLS extensions: - max_fragment_length - client_certificate_url - server_name indication - Supported Elliptic Curves (RFC 4492) - Supported Point Formats (RFC 4492) - SessionTicket (RFC 4507) ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com Axel.Heider@gi-de.com wrote on 07/13/2007 12:19:20 PM: > Hi, > > does anybody on this list know, which servers and browser support > TLS extensions, especially max_fragment_size? > > OpenSSL does not support them in the current version 0.98 (but > upcomming 0.99 may have it when it's released). And Firefox > 2.0.0.4 does not care about the record length, too. > > regards, Axel > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 003AE61B8525731A_= Content-Type: text/html; charset="US-ASCII"
We support the max_fragment_length extension in our SSL-C product. If you want to test interop I'll see if we can enable it on tls.secg.org
The SSL-C product supports the following TLS extensions:
- max_fragment_length        
- client_certificate_url
- server_name indication
- Supported Elliptic Curves  (RFC 4492)
- Supported Point Formats  (RFC 4492)  
- SessionTicket (RFC 4507)


-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

Axel.Heider@gi-de.com wrote on 07/13/2007 12:19:20 PM:

> Hi,
>
> does anybody on this list know, which servers and browser support
> TLS extensions, especially max_fragment_size?
>
> OpenSSL does not support them in the current version 0.98 (but
> upcomming 0.99 may have it when it's released). And Firefox
> 2.0.0.4 does not care about the record length, too.
>
> regards, Axel
>
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 003AE61B8525731A_=-- --===============0671706540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0671706540==-- From tls-bounces@lists.ietf.org Mon Jul 16 06:50:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAOAK-0007Jb-Ae; Mon, 16 Jul 2007 06:50:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAOAI-0007JS-Op for tls@lists.ietf.org; Mon, 16 Jul 2007 06:50:54 -0400 Received: from mail.gi-de.com ([193.108.184.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAOAE-0005XA-Ab for tls@lists.ietf.org; Mon, 16 Jul 2007 06:50:54 -0400 Received: from notessmtp1.domino.intern [10.4.4.49] by mail.gi-de.com id IW4P8JNB outgoing id 190YI2TU; 16 Jul 2007 12:50:49 +0200 In-Reply-To: To: Rob Dugal Subject: Antwort: Re: [TLS] Support for TLS extensions MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Axel.Heider@gi-de.com Date: Mon, 16 Jul 2007 12:50:48 +0200 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 7.0.2|September 26, 2006) at 16.07.2007 12:50:46, Serialize complete at 16.07.2007 12:50:46 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Rob, > We support the max=5Ffragment=5Flength extension in our SSL-C product.=20 > If you want to test interop I'll see if we can enable it on=20 > tls.secg.org=20 If you could enable this, it would be very helpful for testing.=20 --- Mit freundlichen Gr=FCssen / Best regards Axel Heider NB4, Research and Development / Division New Business Giesecke & Devrient GmbH, Prinzregentenstrasse 159, 81677 M=FCnchen, Germany Tel.: +49-(0)89-4119-2693, E-Mail: axel.heider[at]gi-de.com ,=20 http://www.gi-de.com Creating Confidence. -------------------------------------------------------------- Vorsitzender des Aufsichtsrats: Dr. Peter Mihatsch Gesch=E4ftsf=FChrer: Dr. Karsten Ottenberg (Vorsitzender, CEO), Michael Kuemmerle, Hans Wolfgang Kunz, Dr. Walter Schlebusch, Dr. Peter Zattler (CFO) Gesellschaftssitz: M=FCnchen, Handelsregister Amtsgericht M=FCnchen HRB 461= 9.=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 16 07:20:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAOdD-0000PK-EA; Mon, 16 Jul 2007 07:20:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAOcm-00089I-Nk for tls@lists.ietf.org; Mon, 16 Jul 2007 07:20:20 -0400 Received: from curly.its.auckland.ac.nz ([130.216.12.33] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAOci-00066c-7r for tls@lists.ietf.org; Mon, 16 Jul 2007 07:20:20 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 96DF89C2F7; Mon, 16 Jul 2007 23:20:12 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT1kOeP1ikkJ; Mon, 16 Jul 2007 23:20:12 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7B9D59C2F4; Mon, 16 Jul 2007 23:20:12 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CC714D14CFC; Mon, 16 Jul 2007 23:20:10 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1IAOck-0007xx-00; Mon, 16 Jul 2007 23:20:18 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Axel.Heider@gi-de.com, RDugal@certicom.com Subject: Re: [TLS] Support for TLS extensions In-Reply-To: Message-Id: Date: Mon, 16 Jul 2007 23:20:18 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Rob Dugal writes: >We support the max_fragment_length extension in our SSL-C product. If you >want to test interop I'll see if we can enable it on tls.secg.org That'd be most useful, thanks. (Since SECG is probably the reference location for things like the ECC suites, would it be possible to set up a permanent server, not necessarily the main secg.org one, that can be kept online and used in the future for new implementations and for regresssion testing?). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 16 08:07:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAPMK-0001mu-NS; Mon, 16 Jul 2007 08:07:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAPMJ-0001mJ-RM for tls@lists.ietf.org; Mon, 16 Jul 2007 08:07:23 -0400 Received: from mail.ca.certicom.com ([38.113.160.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAPMF-0007fO-Fd for tls@lists.ietf.org; Mon, 16 Jul 2007 08:07:23 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 356DB10027FE4; Mon, 16 Jul 2007 04:08:25 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIp4pf0phkA0; Mon, 16 Jul 2007 04:08:23 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP; Mon, 16 Jul 2007 04:08:23 -0400 (EDT) In-Reply-To: To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Subject: Re: [TLS] Support for TLS extensions MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Mon, 16 Jul 2007 08:02:33 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.2FP1|January 10, 2007) at 07/16/2007 08:03:15 AM, Serialize complete at 07/16/2007 08:03:15 AM X-Spam-Score: 0.5 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: tls@lists.ietf.org, Axel.Heider@gi-de.com X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0745064482==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0745064482== Content-Type: multipart/alternative; boundary="=_alternative 004281408525731A_=" This is a multipart message in MIME format. --=_alternative 004281408525731A_= Content-Type: text/plain; charset="US-ASCII" There has been some recent discussion here about setting up another test server for that purpose. I'm just not sure exactly when it will happen because of other committments, resources, etc. I can probably enable this extension on tls.secg.org in a day or two. ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com pgut001 wrote on 07/16/2007 07:20:18 AM: > Rob Dugal writes: > > >We support the max_fragment_length extension in our SSL-C product. If you > >want to test interop I'll see if we can enable it on tls.secg.org > > That'd be most useful, thanks. > > (Since SECG is probably the reference location for things like the ECC suites, > would it be possible to set up a permanent server, not necessarily the main > secg.org one, that can be kept online and used in the future for new > implementations and for regresssion testing?). > > Peter. --=_alternative 004281408525731A_= Content-Type: text/html; charset="US-ASCII"
There has been some recent discussion here about setting up another test server for that purpose.
I'm just not sure exactly when it will happen because of other committments, resources, etc.
I can probably enable this extension on tls.secg.org in a day or two.

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

pgut001 <pgut001@cs.auckland.ac.nz> wrote on 07/16/2007 07:20:18 AM:

> Rob Dugal <RDugal@certicom.com> writes:
>
> >We support the max_fragment_length extension in our SSL-C product. If you
> >want to test interop I'll see if we can enable it on tls.secg.org
>
> That'd be most useful, thanks.
>
> (Since SECG is probably the reference location for things like the ECC suites,
> would it be possible to set up a permanent server, not necessarily the main
> secg.org one, that can be kept online and used in the future for new
> implementations and for regresssion testing?).
>
> Peter.
 --=_alternative 004281408525731A_=-- --===============0745064482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0745064482==-- From tls-bounces@lists.ietf.org Mon Jul 16 08:55:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAQ77-0001QV-PB; Mon, 16 Jul 2007 08:55:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAQ77-0001QP-2p for tls@lists.ietf.org; Mon, 16 Jul 2007 08:55:45 -0400 Received: from relay1.mail.uk.clara.net ([80.168.70.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAQ73-00011Z-K9 for tls@lists.ietf.org; Mon, 16 Jul 2007 08:55:45 -0400 Received: from [149.254.200.222] (helo=[10.36.129.134]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from ) id 1IAQ6s-0006V8-Tr; Mon, 16 Jul 2007 13:55:38 +0100 Message-ID: <469B6AB7.2090202@drh-consultancy.demon.co.uk> Date: Mon, 16 Jul 2007 13:55:19 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Peter Gutmann Subject: Re: [TLS] Support for TLS extensions References: In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: RDugal@certicom.com, tls@lists.ietf.org, Axel.Heider@gi-de.com X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Peter Gutmann wrote: > Rob Dugal writes: > >> We support the max_fragment_length extension in our SSL-C product. If you >> want to test interop I'll see if we can enable it on tls.secg.org > > That'd be most useful, thanks. > > (Since SECG is probably the reference location for things like the ECC suites, > would it be possible to set up a permanent server, not necessarily the main > secg.org one, that can be kept online and used in the future for new > implementations and for regresssion testing?). > On a similar subject if RFC4507 could be enabled (or if anyone knows a public server or implementation supporting it) that would be great. I'd like to perform some interop testing at some point. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 16 09:46:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAQtp-00078z-ED; Mon, 16 Jul 2007 09:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAQtl-0006vf-II for tls@lists.ietf.org; Mon, 16 Jul 2007 09:46:03 -0400 Received: from mail.gi-de.com ([193.108.184.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAQth-0003Jf-2K for tls@lists.ietf.org; Mon, 16 Jul 2007 09:46:01 -0400 Received: from notessmtp1.domino.intern [10.4.4.49] by mail.gi-de.com id FKY466L6 outgoing id FKY466L6; 16 Jul 2007 15:45:56 +0200 To: tls@lists.ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Axel.Heider@gi-de.com Date: Mon, 16 Jul 2007 15:45:54 +0200 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 7.0.2|September 26, 2006) at 16.07.2007 15:45:54, Serialize complete at 16.07.2007 15:45:54 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [TLS] TLS extensions in ServerHello X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Hello, currently, the TLS 1.2 draft says about the server=5Fhello=5Fextension=5Fli= st: "A list of extensions. Note that only extensions offered by the client can appear in the server's list.". And for the client=5Fhello=5Fextension= =5Flist is says "Clients MAY request extended functionality from servers by sending data in the client=5Fhello=5Fextension=5Flist." As a consequnece, it is impossible for a server to e.g. tell a client to=20 set certain things, if the client did not offer them before. In my case=20 I have a server with very limited resources and a client running on a=20 normal PC with almost no limitations. So the client will usually not=20 send a max=5Ffragemnt=5Flength extension, because it does not really care=20 about this. However, my server cares, but there is no way for it to=20 tell this to the client.=20 Should the spec force the clients to send a list of all supported=20 extensions? Should the server be allowed to send anything in its server=5Fhello=5Fextension=5Flist, if the client said it supports TLS1.2? And if so, how does the client confirm it accepted the extensions send by the server? --- Mit freundlichen Gr=FCssen / Best regards Axel Heider NB4, Research and Development / Division New Business Giesecke & Devrient GmbH, Prinzregentenstrasse 159, 81677 M=FCnchen, Germany Tel.: +49-(0)89-4119-2693, E-Mail: axel.heider[at]gi-de.com ,=20 http://www.gi-de.com Creating Confidence. -------------------------------------------------------------- Vorsitzender des Aufsichtsrats: Dr. Peter Mihatsch Gesch=E4ftsf=FChrer: Dr. Karsten Ottenberg (Vorsitzender, CEO), Michael Kuemmerle, Hans Wolfgang Kunz, Dr. Walter Schlebusch, Dr. Peter Zattler (CFO) Gesellschaftssitz: M=FCnchen, Handelsregister Amtsgericht M=FCnchen HRB 461= 9.=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 16 12:09:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAT8P-0003hr-IT; Mon, 16 Jul 2007 12:09:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAT8N-0003hE-Tz for tls@lists.ietf.org; Mon, 16 Jul 2007 12:09:15 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAT8J-0000zL-Lg for tls@lists.ietf.org; Mon, 16 Jul 2007 12:09:15 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id C7CAA2EF for ; Mon, 16 Jul 2007 12:09:32 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 837AA6474D for ; Mon, 16 Jul 2007 12:09:32 -0400 (EDT) Message-ID: <469B9800.6090806@pobox.com> Date: Mon, 16 Jul 2007 09:08:32 -0700 From: Mike User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Support for TLS extensions References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org >> does anybody on this list know, which servers and browser support TLS >> extensions, especially max_fragment_size? > > My code has support in there for it, but since I've never found anything else > that does it's currently commented out because I haven't been able to do any > interop testing. You can test against https://www.mikestoolbox.net. It supports the max fragment size extension. Not much to test, though, since the server won't choke if it receives a packet that's larger than you specify. It won't send you a larger packet though. It also supports the truncated HMAC extension if you're interested in that. And the server name extension so it will send back a different certificate if you connect to https://www.mikestoolbox.org. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 16 20:46:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAbCy-0007eK-HU; Mon, 16 Jul 2007 20:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAbCx-0007e0-5W for tls@lists.ietf.org; Mon, 16 Jul 2007 20:46:31 -0400 Received: from mailfront2.mn2.visi.com ([208.42.176.213] helo=g2host.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAbCt-000807-PI for tls@lists.ietf.org; Mon, 16 Jul 2007 20:46:31 -0400 Received: from [209.98.144.171] (account mkbrown@visi.com HELO rpud1) by mailfront2.g2host.com (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 9348075; Mon, 16 Jul 2007 19:46:18 -0500 From: "Mark Brown" To: , References: Subject: RE: [TLS] TLS extensions in ServerHello Date: Mon, 16 Jul 2007 19:46:58 -0500 Message-ID: <002101c7c80b$fb8ff6e0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfHr69xIWZsoX3JT9u10fdbzBsb+AAWlmFQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mark@redphonesecurity.com 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: , Errors-To: tls-bounces@lists.ietf.org It would be nice to enhance HelloRequest to handle these circumstances. Currently HelloRequest is empty, e.g.: struct { } HelloRequest; When this message will be sent: The hello request message may be sent by the server at any time. It could be helpful to define HelloRequest as having the same fields as ServerHello. Then the server would have opportunity to suggest stuff to = the client.=20 --mark > -----Original Message----- > From: Axel.Heider@gi-de.com [mailto:Axel.Heider@gi-de.com] > Sent: Monday, July 16, 2007 8:46 AM > To: tls@lists.ietf.org > Subject: [TLS] TLS extensions in ServerHello >=20 > Hello, >=20 > currently, the TLS 1.2 draft says about the = server_hello_extension_list: > "A list of extensions. Note that only extensions offered by the client > can appear in the server's list.". And for the = client_hello_extension_list > is says "Clients MAY request extended functionality from servers by > sending data in the client_hello_extension_list." >=20 > As a consequnece, it is impossible for a server to e.g. tell a client = to > set certain things, if the client did not offer them before. In my = case > I have a server with very limited resources and a client running on a > normal PC with almost no limitations. So the client will usually not > send a max_fragemnt_length extension, because it does not really care > about this. However, my server cares, but there is no way for it to > tell this to the client. >=20 > Should the spec force the clients to send a list of all supported > extensions? Should the server be allowed to send anything in its > server_hello_extension_list, if the client said it supports TLS1.2? > And if so, how does the client confirm it accepted the extensions > send by the server? >=20 >=20 >=20 > --- > Mit freundlichen Gr=FCssen / Best regards >=20 > Axel Heider > NB4, Research and Development / Division New Business > Giesecke & Devrient GmbH, Prinzregentenstrasse 159, 81677 M=FCnchen, = Germany > Tel.: +49-(0)89-4119-2693, E-Mail: axel.heider[at]gi-de.com , > http://www.gi-de.com >=20 > Creating Confidence. > -------------------------------------------------------------- >=20 > Vorsitzender des Aufsichtsrats: Dr. Peter Mihatsch > Gesch=E4ftsf=FChrer: Dr. Karsten Ottenberg (Vorsitzender, CEO), > Michael Kuemmerle, Hans Wolfgang Kunz, > Dr. Walter Schlebusch, Dr. Peter Zattler (CFO) > Gesellschaftssitz: M=FCnchen, Handelsregister Amtsgericht M=FCnchen = HRB 4619. >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 16 23:29:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAdkr-00036v-9L; Mon, 16 Jul 2007 23:29:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAdkp-00035c-N3 for tls@ietf.org; Mon, 16 Jul 2007 23:29:39 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAdkp-0004nM-EI for tls@ietf.org; Mon, 16 Jul 2007 23:29:39 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 16 Jul 2007 20:28:18 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.726.0; Mon, 16 Jul 2007 20:28:18 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jul 2007 20:28:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {D6636E5C-6B9B-4CDB-9310-30C57050A37E} MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: ALsN COTW CRHp CSbw Cfbt EAxh EXbp E0Di E+hH GcWi G1zH H9MS IGKH ISEJ I2cp I6dX; 1; dABsAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {D6636E5C-6B9B-4CDB-9310-30C57050A37E}; bAB6AGgAdQBAAHcAaQBuAGQAbwB3AHMALgBtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Tue, 17 Jul 2007 03:27:43 GMT; dABoAGUAIAB1AHMAZQAgAGMAYQBzAGUAcwAgAGYAbwByACAARwBTAFMALQBiAGEAcwBlAGQAIABUAEwAUwAgAGEAbgBkACAAdABoAGUAIABwAGwAZQBhACAAZgBvAHIAIABpAG4AdABlAGcAcgBhAHQAaQBuAGcAIABLAGUAcgBiAGUAcgBvAHMAIAB3AGkAdABoACAAVABMAFMAOgAgAGQAcgBhAGYAdAAtAHMAYQBuAHQAZQBzAHMAbwBuAC0AdABsAHMALQBnAHMAcwBhAHAAaQA= Content-Class: urn:content-classes:message Date: Mon, 16 Jul 2007 20:27:43 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: the use cases for GSS-based TLS and the plea for integrating Kerberos with TLS: draft-santesson-tls-gssapi Thread-Index: AcfIIm+sPHFKmZq/R5SbQADBE+k9TQ== From: Larry Zhu To: X-OriginalArrivalTime: 17 Jul 2007 03:28:17.0968 (UTC) FILETIME=[846F5300:01C7C822] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [TLS] the use cases for GSS-based TLS and the plea for integrating Kerberos with TLS: draft-santesson-tls-gssapi X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org As we know -02 was published and it integrates Kerberos-alike GSS mechanisms with TLS by importing the GSS key as PSK. It does so to minimize the impact to the TLS state machine. http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt EKR requested us to nail down the use cases for this protocol and explain the rational for the integration. In response, the ID revision -03 contains the use cases and why we want to integrate Kerberos with TLS, particularly in the introduction section. http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx t The flowing document based on email posted by Larry Zhu describes additional background information for the protocol design. http://www.secure-endpoints.com/tls-gss/fka-tls.txt thanks, --larry _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 17 02:18:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAgOW-000626-E3; Tue, 17 Jul 2007 02:18:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAgOU-00061p-8x for tls@lists.ietf.org; Tue, 17 Jul 2007 02:18:46 -0400 Received: from mx.lgsoftindia.com ([203.200.13.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAgOP-0001Hr-Di for tls@lists.ietf.org; Tue, 17 Jul 2007 02:18:46 -0400 Received: from mx.lgsoftindia.com (unknown [127.0.0.1]) by mx.lgsoftindia.com (Symantec Mail Security) with ESMTP id 64D1A2003E7; Tue, 17 Jul 2007 11:32:05 +0530 (IST) X-AuditID: c0a80121-ab7b0bb00000796c-47-469c5b5dd2fe Received: from IT (unknown [192.168.1.34]) by mx.lgsoftindia.com (Symantec Mail Security) with ESMTP id 4D28D2003E5; Tue, 17 Jul 2007 11:32:05 +0530 (IST) Received: from Unknown [172.24.1.102] by IT - SurfControl E-mail Filter (5.0); Tue, 17 Jul 2007 11:48:45 +0530 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 Subject: RE: [TLS] Support for TLS extensions Date: Tue, 17 Jul 2007 11:48:35 +0530 Message-ID: <607194575BD8CE46BCC8D747996FA7F903B03B06@SI-RD10-MS01.LGE.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Support for TLS extensions Thread-Index: AcfFaZz/JB95LVbASe2i+6jcMRCJfgCz8d1w References: From: "Ravi Prasad" To: , X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.7 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Hi, Check this server http://www.gnu.org/software/gnutls/server.html and the server link https://test.gnutls.org:5556/ We tested using a local setup. (We didn't use the online server) Hope this is use full. Thanks and Regards Ravi Prasad -----Original Message----- From: Axel.Heider@gi-de.com [mailto:Axel.Heider@gi-de.com] Sent: Friday, July 13, 2007 9:49 PM To: tls@lists.ietf.org Subject: [TLS] Support for TLS extensions Hi, does anybody on this list know, which servers and browser support TLS extensions, especially max_fragment_size? OpenSSL does not support them in the current version 0.98 (but upcomming 0.99 may have it when it's released). And Firefox 2.0.0.4 does not care about the record length, too. regards, Axel _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls #########################################=0A= THIS EMAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT(S) AND MAY= CONTAIN CONFIDENTIAL AND PRIVILEGED INFORMATION. ANY UNAUTHORIZED REVIEW, U= SE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED.BEFORE OPENING ANY ATTACHMENTS= PLEASE CHECK FOR VIRUSES AND DEFECTS.IF YOU ARE NOT THE INTENDED RECIPIENT,= PLEASE NOTIFY US IMMEDIATELY BY REPLY E-MAIL AND DELETE THE ORIGINAL MESSAG= E.=0A= ######################################### _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From lottery_board25@bellsouth.net Tue Jul 17 08:16:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAlyW-0004xf-LP; Tue, 17 Jul 2007 08:16:20 -0400 Received: from imf22aec.mail.bellsouth.net ([205.152.59.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAlyS-0004s5-BQ; Tue, 17 Jul 2007 08:16:20 -0400 Received: from ibm65aec.bellsouth.net ([192.168.16.253]) by imf22aec.mail.bellsouth.net with ESMTP id <20070717121616.JBYR9665.imf22aec.mail.bellsouth.net@ibm65aec.bellsouth.net>; Tue, 17 Jul 2007 08:16:16 -0400 Received: from mail.bellsouth.net ([192.168.16.253]) by ibm65aec.bellsouth.net with SMTP id <20070717121615.VWDS275.ibm65aec.bellsouth.net@mail.bellsouth.net>; Tue, 17 Jul 2007 08:16:15 -0400 X-Mailer: Openwave WebEngine, version 2.8.16.1 (webedge20-101-1106-101-20040924) X-Originating-IP: [63.247.79.145] From: LOTTERY BOARD Reply-To: contact_claimsagent_spencer09@yahoo.co.uk Organization: LOTTERY BOARD To: Subject: Congratulations....**Your Email Has Made You A Winner** Date: Tue, 17 Jul 2007 8:16:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20070717121615.VWDS275.ibm65aec.bellsouth.net@mail.bellsouth.net> X-Spam-Score: 2.9 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 11 G Lower Dorset Street, Dublin 1, Ireland. P O Box 1010. ONLINE- NOTIFICATION We are pleased to inform you today 17, July, 2007 of the result of the winners of the IRISH NATIONAL LOTTERY ONLINE PROMO PROGRAMME, held on the Saturday 14th July 2007, ticketnumber:56475600545 188 with Serial number 5368/02 this are your lucky numbers:07, 08, 11, 17, 21, 33, Bonus 44 You have therefore been approved for a lump sum pay out of £1,350,000(One million, three hundred and fifty thousand, pounds sterling) in cash credited to file INLPG/9023318308/07. To file for your claim, please contact our fiduciary agent in the email address below: Mr. Spencer Brown Email: claimsagent_williams06@yahoo.co.uk Tel: (+44)-7024066880 Tel: (+44) 701113 7597 Provide him with the information below: 1.Full Name: 2.Full Address: 3.Marital Status: 4.Occupation: 5.Age: 6.Sex: 7.Nationality: 8.Country Of Residence: 9.Telephone Number: 10.Company Name (If Any): Congratulations once more from all members and staff of this program. Sincerely, Sir.kolyn parkins Online coordinator for THE IRISH LOTTERY Sweepstakes International Program. From tls-bounces@lists.ietf.org Tue Jul 17 14:41:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAryo-0001OP-Vy; Tue, 17 Jul 2007 14:41:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAryk-0001CP-Q6 for tls@ietf.org; Tue, 17 Jul 2007 14:40:58 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAryk-00030I-Az for tls@ietf.org; Tue, 17 Jul 2007 14:40:58 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id UAA15106; Tue, 17 Jul 2007 20:40:42 +0200 (MESZ) From: Martin Rex Message-Id: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating To: lzhu@windows.microsoft.com (Larry Zhu) Date: Tue, 17 Jul 2007 20:40:42 +0200 (MEST) In-Reply-To: from "Larry Zhu" at Jul 16, 7 08:27:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Larry Zhu wrote: > > As we know -02 was published and it integrates Kerberos-alike GSS > mechanisms with TLS by importing the GSS key as PSK. It does so to > minimize the impact to the TLS state machine. > > http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt > > EKR requested us to nail down the use cases for this protocol and > explain the rational for the integration. On first reading, it doesn't appear much different from the last proposal und suffers the same problems - The GSS-API token exchange is still within the TLS handshake (a little earlier than in the last proposal, but still within and with an unpredictable amount of additonal round-trips). - It requires hostbased service names plus mutual authentication, altough the majority of gssapi mechanism does not implement hostbased service names and a significant fraction of "simple" gssapi mechanisms doesn't provide acceptor-to-initiator authentication at all. - It requires the brand-new optional extension "GSS_Pseudo_random" from a gss-api mechanism, which the majority of existing mechanism do not implement, and which can not be provided by a significant fraction of gss-api mechanisms that do not provide confidentiality protection and is impossible to provide by authentication-only mechanisms. - it performs the gssapi handshake in the clear before the TLS encryption applied. It would be much better if the GSS-API authentication is performed within a tunnel that is already TLS-protected, so that the cryptographic strength of both add up for network-level attacks. Recent TLS implementations provide fairly strong protection, and to make use of any TLS extension in this area, a new TLS implementation will be required. The involved GSS-API mechanism will almost always be legacy, and fairly weak in comparison to a recent TLS. Doing it in the fashion that Stefan is looking for means that one will have to merge GSS-API and TLS with a sledge hammer, and will be extremely difficult to impossible to adopt by very common environments that terminate the SSL/TLS communication at the edge of a backend distributed system (reverse proxies, SSL Accellerators as closed third-party boxes, etc.) Personally, I firmly (and still) believe that this is an entirely wrong approach. The most interesting aspect of GSS-API is being able to authenticate clients (because this is where the costs are when personalizing credentials). For the server side, the authentication should be designed to always support both, GSS-API based authentication AND SSL-Server certificate based authentication, to provide the interoperability with the installed base that one has come to expect from SSL/TLS. The most sensible approach, and the one with the least impact on existing TLS would IMHO be to perform GSS-API authentication after a regular TLS handshake and use channel bindings based on existing TLS secure channel information. With such a design no changes to the TLS state machine are necessary, only an extension to signal/negotiate availability/use of the additional message exchange following the TLS handshake. For distributed servers, it would even be possible to move the GSS-API handshake entirely into the backend (and not on the reverse proxies, SSL accellerators and such). The necessary hooks into SSL/TLS are an extension indicator for the handshake plus the secure channel bindings info of the underlying SSL/TLS session, and that is completely independent of any particular gssapi mechanism. Building a additional layer which calls into your favorite GSS-API off-the-shelf GSS-API mechanism and also into a pretty much vanilla TLS stack, while providing an API to applications that look like a regular TLS stack will be a much more sensible approach to the underyling problem. I would not want to see a forced marriage of TLS with GSS-API, where TLS needs to be changed significantly, and where there are so many limitations on what GSS-API mechanisms may be used with this and the resulting impact on security. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 17 15:24:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAseR-0006xJ-OM; Tue, 17 Jul 2007 15:24:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAseQ-0006kF-7l for tls@ietf.org; Tue, 17 Jul 2007 15:24:02 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAseP-0004kx-Hr for tls@ietf.org; Tue, 17 Jul 2007 15:24:02 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 17 Jul 2007 12:24:00 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.726.0; Tue, 17 Jul 2007 12:23:58 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jul 2007 12:23:58 -0700 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 Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating Date: Tue, 17 Jul 2007 12:23:08 -0700 Message-ID: In-Reply-To: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] the use cases for GSS-based TLS and the plea for integrating Thread-Index: AcfIogyuRdLBGIFqQdatVidnmaLHxgAALDhw References: from "Larry Zhu" at Jul 16, 7 08:27:43 pm <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> From: Larry Zhu To: X-OriginalArrivalTime: 17 Jul 2007 19:23:58.0591 (UTC) FILETIME=[061C08F0:01C7C8A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > - It requires hostbased service names plus mutual authentication, > altough the majority of gssapi mechanism does not implement > hostbased service names and a significant fraction of > "simple" gssapi mechanisms doesn't provide acceptor-to-initiator > authentication at all. Where is the acceptor-to-initiator introduced here? >- It requires the brand-new optional extension "GSS_Pseudo_random" > from a gss-api mechanism, which the majority of existing > mechanism do not implement, and which can not be provided > by a significant fraction of gss-api mechanisms that do > not provide confidentiality protection and is impossible to > provide by authentication-only mechanisms. I beg to disagree on this. The FXA-TLS ID defines a generic and extensible mechanism to allow=20 the use of off-shelf GSS-API libraries, but it does not encourage the use of arbitrary GSS-API mechanism for the TLS handshake. Apps will pick and choose which GSS-API mechanism to support. This is in analogy and consistent with the fact that how you choose to negotiate the RFC4279 PSK cipher suites. This differs from RFC4279 in that using RFC4279 you do not authenticate the server other than to the extend that the server knows the shared key and that key may be shared among multiple services on the server host. The GSS PRF is designed to be very light-weighted to be implemented. Most existing GSS-API already have implemented it one way or the other. The PRF RFC is new, but it is not new at all to implementations. >- it performs the gssapi handshake in the clear before the > TLS encryption applied. It would be much better if the > GSS-API authentication is performed within a tunnel that > is already TLS-protected, so that the cryptographic > strength of both add up for network-level attacks. If an GSS-API mechanism cannot work without TLS protection, it should NOT be selected according to this draft. Furthermore this draft does not prevent the gss-api data from being protected by TLS. People want to do that already do it. It is just not within the scope of this draft.=20 This draft wants to move the GSS-API down to the TLS stack. This way all upper layer protocols would benefit from it automatically if it is chosen based on the negotiation layer. > Recent TLS implementations provide fairly strong protection, > and to make use of any TLS extension in this area, a new TLS > implementation will be required. The involved GSS-API mechanism > will almost always be legacy, and fairly weak in comparison to > a recent TLS. Can you provide a concrete example? And we can analyze that if you do. I do not have an example myself, but I can envision similar advances would have to be made into Kerberos, and we do not lose the protection end-to-end in such situations. Integrating GSS with TLS gives us the most economical way to innovate and reduce the proliferation of mechanisms. > Doing it in the fashion that Stefan is looking for means that one will have to merge GSS-API and TLS with a sledge hammer, and will be extremely >=20 > difficult to impossible to adopt by very common environments that terminate the SSL/TLS communication at the edge of a backend distributed >=20 > system(reverse proxies, SSL Accellerators as closed third-party boxes, etc.) Not all gss-api mechanisms are created equal. The TLS client need to choose the GSS-API mechanism in the same way it need to select which set of ciphersuites to support. This is a very consistent and time-proven model. There is no one arguing for a plug-&-play model that allows the plug-in of any GSS-API mechanism to TLS. I would like to request to have meaningful technical discussions before making a conclusion prematurely.=20 The scenarios for securing TLS using Kerberos are very compelling, and this draft provides the simplest way to provide a secure solution that the industry badly need. The industry will do it with or without IETF.=20 If IETF wants to stay relevant in today's fast paced world, it should not delay the process and work out a solution that is consistent with the IETF framework. The current process is simply not acceptable and completely violates the IETF tenet. > The most interesting aspect of GSS-API is being able to authenticate > clients (because this is where the costs are when personalizing > credentials). For the server side, the authentication should > be designed to always support both, GSS-API based authentication > AND SSL-Server certificate based authentication, to provide the > interoperability with the installed base that one has come to > expect from SSL/TLS. Yes, this is specifically called out in -03. We have a separate section for it. >Building a additional layer which calls into your favorite >GSS-API off-the-shelf GSS-API mechanism and also into >a pretty much vanilla TLS stack, while providing an API >to applications that look like a regular TLS stack >will be a much more sensible approach to the underyling problem. Again, I have stated my points on this just now. --larry -----Original Message----- From: Martin Rex [mailto:Martin.Rex@sap.com]=20 Sent: Tuesday, July 17, 2007 11:41 AM To: Larry Zhu Cc: tls@ietf.org Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating Larry Zhu wrote: >=20 > As we know -02 was published and it integrates Kerberos-alike GSS > mechanisms with TLS by importing the GSS key as PSK. It does so to > minimize the impact to the TLS state machine. >=20 > http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt >=20 > EKR requested us to nail down the use cases for this protocol and > explain the rational for the integration. On first reading, it doesn't appear much different from the last proposal und suffers the same problems - The GSS-API token exchange is still within the TLS handshake (a little earlier than in the last proposal, but still within and with an unpredictable amount of additonal round-trips). - It requires hostbased service names plus mutual authentication, altough the majority of gssapi mechanism does not implement hostbased service names and a significant fraction of "simple" gssapi mechanisms doesn't provide acceptor-to-initiator authentication at all. - It requires the brand-new optional extension "GSS_Pseudo_random" from a gss-api mechanism, which the majority of existing mechanism do not implement, and which can not be provided by a significant fraction of gss-api mechanisms that do not provide confidentiality protection and is impossible to provide by authentication-only mechanisms. - it performs the gssapi handshake in the clear before the TLS encryption applied. It would be much better if the GSS-API authentication is performed within a tunnel that is already TLS-protected, so that the cryptographic strength of both add up for network-level attacks. =20 - it performs the gssapi handshake in the clear before the TLS encryption applied. It would be much better if the GSS-API authentication is performed within a tunnel that is already TLS-protected, so that the cryptographic strength of both add up for network-level attacks. Doing it in the fashion that Stefan is looking for means that one will have to merge GSS-API and TLS with a sledge hammer, and will be extremely difficult to impossible to adopt by very common environments that terminate the SSL/TLS communication at the edge of a backend distributed system (reverse proxies, SSL Accellerators as closed third-party boxes, etc.) Personally, I firmly (and still) believe that this is an entirely wrong approach. The most interesting aspect of GSS-API is being able to authenticate clients (because this is where the costs are when personalizing credentials). For the server side, the authentication should be designed to always support both, GSS-API based authentication AND SSL-Server certificate based authentication, to provide the interoperability with the installed base that one has come to expect from SSL/TLS. The most sensible approach, and the one with the least impact on existing TLS would IMHO be to perform GSS-API authentication after a regular TLS handshake and use channel bindings based on existing TLS secure channel information. With such a design no changes to the TLS state machine are necessary, only an extension to signal/negotiate availability/use of the additional message exchange following the TLS handshake. For distributed servers, it would even be possible to move the GSS-API handshake entirely into the backend (and not on the reverse proxies, SSL accellerators and such). The necessary hooks into SSL/TLS are an extension indicator for the handshake plus the secure channel bindings info of the underlying SSL/TLS session, and that is completely independent of any particular gssapi mechanism. Building a additional layer which calls into your favorite GSS-API off-the-shelf GSS-API mechanism and also into a pretty much vanilla TLS stack, while providing an API to applications that look like a regular TLS stack will be a much more sensible approach to the underyling problem. I would not want to see a forced marriage of TLS with GSS-API, where TLS needs to be changed significantly, and where there are so many limitations on what GSS-API mechanisms may be used with this and the resulting impact on security.=20 -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 17 16:37:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAtnn-0003Ys-AI; Tue, 17 Jul 2007 16:37:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAtnm-0003YC-Hm for tls@lists.ietf.org; Tue, 17 Jul 2007 16:37:46 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAtnl-0006n0-5R for tls@lists.ietf.org; Tue, 17 Jul 2007 16:37:46 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA20793; Tue, 17 Jul 2007 22:37:39 +0200 (MESZ) From: Martin Rex Message-Id: <200707172037.l6HKbdbS026319@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating To: lzhu@windows.microsoft.com (Larry Zhu) Date: Tue, 17 Jul 2007 22:37:39 +0200 (MEST) In-Reply-To: from "Larry Zhu" at Jul 17, 7 12:23:08 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Larry Zhu wrote: > > Martin Rex wrote: > > - It requires hostbased service names plus mutual authentication, > > altough the majority of gssapi mechanism does not implement > > hostbased service names and a significant fraction of > > "simple" gssapi mechanisms doesn't provide acceptor-to-initiator > > authentication at all. > > Where is the acceptor-to-initiator introduced here? The FXA-TLS ID says "the client MUST request mutual authentication" and continues with "MUST fail if not available", and this is where it obviously introduces the "acceptor-to-initiator" authentication. GSS-API traditionally implied initiator-to-acceptor authentication. When the initiator requests "mutual authentication", it is actually a request for "acceptor-to-initiator" authentication. The "acceptor-to-initiator only" authentication, which is what is commonly used by Web-Browsers with HTTPS these days would be GSS-API with anonymous client credentials requesting mutual authentication Anonymous (initiator) credentials are not very well-defined and supported by very few gssapi mechanisms these days). Anonymous acceptor credentials are somewhat more common, they're required for gssapi mechanisms that are unable to perform acceptor-to-initiator authentication, e.g. challenge-response mechanisms like NTLM. So the mutual flag is somewhat of a misnomer, witnessing that originally one didn't think about mechanisms where the client would not be authenticated. > > >- It requires the brand-new optional extension "GSS_Pseudo_random" > > from a gss-api mechanism, which the majority of existing > > mechanism do not implement, and which can not be provided > > by a significant fraction of gss-api mechanisms that do > > not provide confidentiality protection and is impossible to > > provide by authentication-only mechanisms. > > I beg to disagree on this. The FXA-TLS ID defines a generic and > extensible mechanism to allow > the use of off-shelf GSS-API libraries, but it does not encourage the > use of arbitrary GSS-API mechanism for the TLS handshake. > Apps will pick and choose which GSS-API mechanism to support. > > This is in analogy and consistent with the fact that how you choose to > negotiate the RFC4279 PSK cipher suites. This differs from RFC4279 in > that using RFC4279 you do not authenticate the server other than to the > extend that the server knows the shared key and that key may be shared > among multiple services on the server host. PSK cipher suites are already a big prerequisite and significant unnecessary burden. I would prefer an extension approach that could be built with minor modifications to an existing SSLv3-only stack in a small amount of time, using only the available SSL ciphersuites. > > The GSS PRF is designed to be very light-weighted to be implemented. > Most existing GSS-API already have implemented it one way or the other. > The PRF RFC is new, but it is not new at all to implementations. I'm not aware that there is a generic GSS PRF spec. I know there is one for Kerberos, and that some people confuse GSS-API with Kerberos. Implementors of SPKM (rfc-2025) will first have to standardize on a prf before they can implement it, which is a HUGE burden. > > >- it performs the gssapi handshake in the clear before the > > TLS encryption applied. It would be much better if the > > GSS-API authentication is performed within a tunnel that > > is already TLS-protected, so that the cryptographic > > strength of both add up for network-level attacks. > > If an GSS-API mechanism cannot work without TLS protection, it should > NOT be selected according to this draft. I didn't say that it can not work without, just that the security level of the GSS-API mechanism itself is marginal at best when compared to TLS. I think that a protocol providing a standardized GSS-API authentication for a TLS-protected communication channel should not discriminate against or preclude whole classes of gssapi mechanism -- if it did, it should not be considered for IETF standards track, because we certainly can do much better. > > Furthermore this draft does not > prevent the gss-api data from being protected by TLS. People want to do > that already do it. It is just not within the scope of this draft. It unecessarily puts the authentication exchange into the cleartext section of the TLS handshake. We already know that this is considered a problem for the client certificate message in the existing SSL/TLS handshake, why should we repeat this known mistake when it can be easily avoided? > > This draft wants to move the GSS-API down to the TLS stack. This way all > upper layer protocols would benefit from it automatically if it is > chosen based on the negotiation layer. I'm all for layering protocol stacks. However I totally disagree about the layering sequence. I firmly believe that the GSS-API implementation should be called by a communication layer on top of regular TLS, and provide a TLS-with-added-value, instead of a forced marriage as required for FXA-TLS and its predecessor proposal. > > > > Recent TLS implementations provide fairly strong protection, > > and to make use of any TLS extension in this area, a new TLS > > implementation will be required. The involved GSS-API mechanism > > will almost always be legacy, and fairly weak in comparison to > > a recent TLS. > > Can you provide a concrete example? And we can analyze that if you do. I > do not have an example myself, but I can envision similar advances would > have to be made into Kerberos, and we do not lose the protection > end-to-end in such situations. Integrating GSS with TLS gives us the > most economical way to innovate and reduce the proliferation of > mechanisms. You should know pretty well. You're involved in the FAST-Armor vs. StartTLS discussion which addresses know weaknesses in specific authentication exchanges that are in common use and can not be easily abandoned. Many WindowsXPsp2 machines perform regular NTLM authentications these days because of a serious bug in the sp2 Kerberos.dll. (which is fixed by KB885887, but that Hotfix is still not publicly available and SP3 is delayed for whatever strategic reasons). > > > Doing it in the fashion that Stefan is looking for means that one will > have to merge GSS-API and TLS with a sledge hammer, and will be > extremely > > > difficult to impossible to adopt by very common environments that > terminate the SSL/TLS communication at the edge of a backend distributed > > > > system(reverse proxies, SSL Accellerators as closed third-party boxes, > etc.) > > Not all gss-api mechanisms are created equal. The TLS client need to > choose the GSS-API mechanism in the same way it need to select which set > of ciphersuites to support. This is a very consistent and time-proven > model. There is no one arguing for a plug-&-play model that allows the > plug-in of any GSS-API mechanism to TLS. There is significant interest in plug-n-play arbitrary gssapi mechanisms into a single gssapi multi-mechanism. Is it really that difficult to predict that people will want a choice of the gssapi mechanism that they use with TLS? The one thing that can be loaded off to (the) TLS (handshake) is the common gssapi mechanism selection (no optimistic token). But that could be done in a fairly generic black box fashion (independent of any particular gssapi mechanism/implementation). I consider the lack of support for virtual hosts in (base) SSL/TLSv1 an issue that should be addressed and solved by a GSS-API authentication for TLS standard. And it should be solved in a transparent fashion for TLS using a regular SSL server certs and TLS using GSS-API based server authentication. Very few GSS-API mechanisms allow for "automatic selection" of server credentials during gss_accept_sec_context(). Since the creation of credentials is EXPLICITLY made a local issue of an implementation, no standard based on GSS-API should make an assumption as to whether a gssapi mechanism can automatically determine and correctly acquire a matching server credential when gss_accept_sec_context is called with GSS_C_NO_CREDENTIAL. In fact, most gssapi mechanism implementation are not able to do this. > > I would like to request to have meaningful technical discussions before > making a conclusion prematurely. > > > > The scenarios for securing TLS using Kerberos are very compelling, and > this draft provides the simplest way to provide a secure solution that > the industry badly need. The industry will do it with or without IETF. I thought this is about authentication a secure TLS channel using a GSS-API mechanis. I agree that such a possibility would be greatly appreciated. We currently have the situation that we can use GSS-API based Single Sign-On with our legacy frontends, but not with the HTTP-based newer frontends. Right now, single sign-on is only possible if the GSS-API based Single Sign-On is based on PKI (i.e. SPKM-like) with X.509 certs and offers a possibility to furnish the browser with either the PKI credentials or a PKCS#11 access to these credentials. The possibility to offer GSS-API based authentication for the HTTP-based access as well would be great, but in order to support that on our backends, we would need an approach which flies with NO CHANGES whatsoever to an existing GSS-API mechanism and EXTREMELY low impact changes to an exiting SSLv3 implementation... > > If IETF wants to stay relevant in today's fast paced world, it should > not delay the process and work out a solution that is consistent with > the IETF framework. The current process is simply not acceptable and > completely violates the IETF tenet. > > We are already at a level of complexity where dirty hacks will create HUGE problems already in the short run. There are no such things as homogeneous environments. And even the homogeneous new installations that your seem to have in mind are going to the the heterogeneous environments of tomorrow, when a new feature or scheme comes up that people what to use (and for which they need a migration path). If we get smooth cooperation of GSS-API based and traditional certificate-based Server authentication this time around, this will likely reduce the pain and suffering for the next transition. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 17 17:42:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAunz-0003y2-O7; Tue, 17 Jul 2007 17:42:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAunx-0003xu-Kc for tls@ietf.org; Tue, 17 Jul 2007 17:42:01 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAunv-0008Vb-OL for tls@ietf.org; Tue, 17 Jul 2007 17:42:01 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA26056; Tue, 17 Jul 2007 23:41:53 +0200 (MESZ) From: Martin Rex Message-Id: <200707172141.l6HLfqU9000857@fs4113.wdf.sap.corp> Subject: Re: [TLS] GSS based PSK-TLS To: lzhu@windows.microsoft.com (Larry Zhu) Date: Tue, 17 Jul 2007 23:41:52 +0200 (MEST) In-Reply-To: from "Larry Zhu" at Jul 13, 7 04:46:12 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Larry Zhu wrote: > > We would like to request for comments for the GSS based PSK-TLS ID: > > http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt > > 2) Why the GSS handshake does not come after the key exchange message? > > We do not want to pay for the cost of the DHE or RSA in this case. > The main motivation for us is to enable Kerberos to secure TLS > connections. > Kerberos is a lot faster, and we intend to keep it that way. TLS session can be cached, resumed and forked. Although performance is an issue for a significant amount of our customers, the RSA-server-authentication in the SSL handshake is NOT normally an issue (it only becomes an issue if the SSL session cache is configured too small). So-called SSL Accellerators have a really hard time to provide a benefit. They might add latency and an additional point of failures, and can hardly keep up with x86-based multi-cpu multi-core machines (both in terms of price and performance). GSS-API security context can not be cached and not be resumed. A while ago I looked with HTTPWatch at the messages exchanged between MSIE6 and IIS6 using HTTPS+Negotiate. IIS6 forces the client with 401 Unauthorized through a full new Kerberos authentication with each and every request on an established TLS channel. I'm not impressed, and will not easily buy "proposed solutions" for Microsoft-asserted performance issues. And why is TLS authentication performance made a non-issue for StartTLS vs FastArmor and a big issue here? -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 17 18:40:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAvim-0008Ba-5k; Tue, 17 Jul 2007 18:40:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAvik-00088Y-2e for tls@ietf.org; Tue, 17 Jul 2007 18:40:42 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAvii-0001iG-Rh for tls@ietf.org; Tue, 17 Jul 2007 18:40:42 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 17 Jul 2007 15:40:40 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) with Microsoft SMTP Server id 8.0.726.0; Tue, 17 Jul 2007 15:40:39 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jul 2007 15:40:39 -0700 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 Subject: RE: [TLS] GSS based PSK-TLS Date: Tue, 17 Jul 2007 15:40:10 -0700 Message-ID: In-Reply-To: <200707172141.l6HLfqU9000857@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] GSS based PSK-TLS Thread-Index: AcfIu1MBtrWytsHnQga/Cm3wjwUK3gAB3EFg References: from "Larry Zhu" at Jul 13, 7 04:46:12 pm <200707172141.l6HLfqU9000857@fs4113.wdf.sap.corp> From: Larry Zhu To: X-OriginalArrivalTime: 17 Jul 2007 22:40:39.0234 (UTC) FILETIME=[7FD74220:01C7C8C3] X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > TLS session can be cached, resumed and forked. Although performance is an issue for a significant amount of our customers, the RSA-server- > authentication in the SSL handshake is NOT normally an issue (it only becomes an issue if the SSL session cache is configured too small). So-called=20 > SSL Accellerators have a really hard time to provide a benefit. They might add latency and an additional point of failures, and can hardly keep up=20 > with x86-based multi-cpu multi-core machines (both in terms of price and performance). This will continue to work. I would like to emphasize FKA-TLS is a variant of PSK-TLS. > GSS-API security context can not be cached and not be resumed. you do not need to resume in the GSS level. You can resume in the PSK-TLS level. Again, this is a variant of PSK-TLS, you have all the bells and whistlers of PSK-TLS. --larry -----Original Message----- From: Martin Rex [mailto:Martin.Rex@sap.com]=20 Sent: Tuesday, July 17, 2007 2:42 PM To: Larry Zhu Cc: tls@ietf.org Subject: Re: [TLS] GSS based PSK-TLS Larry Zhu wrote: >=20 > We would like to request for comments for the GSS based PSK-TLS ID: >=20 > http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt >=20 > 2) Why the GSS handshake does not come after the key exchange message? >=20 > We do not want to pay for the cost of the DHE or RSA in this case.=20 > The main motivation for us is to enable Kerberos to secure TLS > connections.=20 > Kerberos is a lot faster, and we intend to keep it that way. TLS session can be cached, resumed and forked. Although performance is an issue for a significant amount of our customers, the RSA-server-authentication in the SSL handshake is NOT normally an issue (it only becomes an issue if the SSL session cache is configured too small). So-called SSL Accellerators have a really hard time to provide a benefit. They might add latency and an additional point of failures, and can hardly keep up with x86-based multi-cpu multi-core machines (both in terms of price and performance). GSS-API security context can not be cached and not be resumed. A while ago I looked with HTTPWatch at the messages exchanged between MSIE6 and IIS6 using HTTPS+Negotiate. IIS6 forces the client with 401 Unauthorized through a full new Kerberos authentication with each and every request on an established TLS channel. I'm not impressed, and will not easily buy "proposed solutions" for Microsoft-asserted performance issues. And why is TLS authentication performance made a non-issue for StartTLS vs FastArmor and a big issue here? -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 17 19:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAw9F-0002mn-Cn; Tue, 17 Jul 2007 19:08:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAw66-0003fS-3Y for tls@lists.ietf.org; Tue, 17 Jul 2007 19:04:50 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAw64-0002Hr-M4 for tls@lists.ietf.org; Tue, 17 Jul 2007 19:04:50 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 17 Jul 2007 16:04:48 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) with Microsoft SMTP Server id 8.0.726.0; Tue, 17 Jul 2007 16:04:47 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jul 2007 16:04:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {7BE82357-04AA-4C6D-AADE-141C088606A4} MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: AhMH B1Ra CuW2 Fb+e FnWs HNsI Jmgs LQa0 Ol3A PlJ2 RhrW RjnJ Wibi Wtk1 Xy3a YUVb; 2; bQBhAHIAdABpAG4ALgByAGUAeABAAHMAYQBwAC4AYwBvAG0AOwB0AGwAcwBAAGwAaQBzAHQAcwAuAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {7BE82357-04AA-4C6D-AADE-141C088606A4}; bAB6AGgAdQBAAHcAaQBuAGQAbwB3AHMALgBtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Tue, 17 Jul 2007 23:04:22 GMT; UgBFADoAIABbAFQATABTAF0AIAB0AGgAZQAgAHUAcwBlACAAYwBhAHMAZQBzACAAZgBvAHIAIABHAFMAUwAtAGIAYQBzAGUAZAAgAFQATABTACAAYQBuAGQAIAB0AGgAZQAgAHAAbABlAGEAIABmAG8AcgAgAGkAbgB0AGUAZwByAGEAdABpAG4AZwA= Content-Class: urn:content-classes:message Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating Date: Tue, 17 Jul 2007 16:04:22 -0700 Message-ID: In-Reply-To: <200707172037.l6HKbdbS026319@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] the use cases for GSS-based TLS and the plea for integrating Thread-Index: AcfIsmD3OcEBLZz5S8mlA+gxUZlPagAA+Z5g References: from "Larry Zhu" at Jul 17, 7 12:23:08 pm <200707172037.l6HKbdbS026319@fs4113.wdf.sap.corp> From: Larry Zhu To: X-OriginalArrivalTime: 17 Jul 2007 23:04:46.0631 (UTC) FILETIME=[DE8E8370:01C7C8C6] X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > The FXA-TLS ID says "the client MUST request mutual authentication" > and continues with "MUST fail if not available", and this is where > it obviously introduces the "acceptor-to-initiator" authentication. > GSS-API traditionally implied initiator-to-acceptor authentication. > When the initiator requests "mutual authentication", it is actually > a request for "acceptor-to-initiator" authentication. > The "acceptor-to-initiator only" authentication, which is what is > commonly used by Web-Browsers with HTTPS these days would be > GSS-API with anonymous client credentials requesting mutual authentication > Anonymous (initiator) credentials are not very well-defined and > supported by very few gssapi mechanisms these days). Anonymous > acceptor credentials are somewhat more common, they're required > for gssapi mechanisms that are unable to perform acceptor-to-initiator > authentication, e.g. challenge-response mechanisms like NTLM. > So the mutual flag is somewhat of a misnomer, witnessing that > originally one didn't think about mechanisms where the client > would not be authenticated. Let's move pass this please. I would clarify that this ID does not call for acceptor-to-initiator authentication. > PSK cipher suites are already a big prerequisite and significant > unnecessary burden. > I would prefer an extension approach that could be built with minor > modifications to an existing SSLv3-only stack in a small amount of time, > using only the available SSL ciphersuites. Throw you ideas, you have all my ears. Personally I believe the existing selection that is based on the cipher suites works fine and it is a time-proven model. I would object to adding extra complexity here. > I'm not aware that there is a generic GSS PRF spec. I know there is > one for Kerberos, and that some people confuse GSS-API with Kerberos. > Implementors of SPKM (rfc-2025) will first have to standardize > on a prf before they can implement it, which is a HUGE burden. Let me reiterate, the PRF RFC is new, but the PRF operation is not new to implementations. And let me also reiterate that the ID does not want to plug in any GSS-API mechanism. SPKM is a deprecated and broken one that IETF does not intend to support. We have enough said, please move on. > I didn't say that it can not work without, just that the security > level of the GSS-API mechanism itself is marginal at best when > compared to TLS. > I think that a protocol providing a standardized GSS-API authentication > for a TLS-protected communication channel should not discriminate against > or preclude whole classes of gssapi mechanism -- if it did, it should > not be considered for IETF standards track, because we certainly can > do much better. It is the choice of the policy as how cipher suites are selected today. This ID does not change that, please move on for this. > It unecessarily puts the authentication exchange into the cleartext > section of the TLS handshake. We already know that this is considered > a problem for the client certificate message in the existing > SSL/TLS handshake, why should we repeat this known mistake when > it can be easily avoided? You can use TLS protect the handshake, you can do that today. How to do that is just NOT within the scope of this draft. Again, in certain aspects, we are just trying to make PSK-TLS more deployable and fix the mutual auth problem in PSK-TLS. We move the GSS-API handshake down to the TLS stack to provide a platform solution so everything on top can benefit from it. > I'm all for layering protocol stacks. However I totally disagree > about the layering sequence. I firmly believe that the GSS-API > implementation should be called by a communication layer on top > of regular TLS, and provide a TLS-with-added-value, instead > of a forced marriage as required for FXA-TLS and its predecessor > proposal. GSS-API is designed to work without TLS protection. Just think how SASL works you should appreciate the work here. > You should know pretty well. You're involved in the FAST-Armor vs. StartTLS > discussion which addresses know weaknesses in specific > authentication exchanges that are in common use and can not be easily > abandoned. > Many WindowsXPsp2 machines perform regular NTLM authentications these days > because of a serious bug in the sp2 Kerberos.dll. (which is fixed by >>KB885887, but that Hotfix is still not publicly available and SP3 > is delayed for whatever strategic reasons). I do not know how you can relate any of these to this work. > We are already at a level of complexity where dirty hacks will create > HUGE problems already in the short run. This is a generic and extensible solution. > There are no such things as homogeneous environments. And even > the homogeneous new installations that your seem to have in mind > are going to the the heterogeneous environments of tomorrow, when > a new feature or scheme comes up that people what to use (and > for which they need a migration path). > If we get smooth cooperation of GSS-API based and traditional > certificate-based Server authentication this time around, this > will likely reduce the pain and suffering for the next > transition. Again, I do not know how any of the points you raised is related to the work here. --larry -----Original Message----- From: Martin Rex [mailto:Martin.Rex@sap.com]=20 Sent: Tuesday, July 17, 2007 1:38 PM To: Larry Zhu Cc: tls@lists.ietf.org Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating Larry Zhu wrote: >=20 > Martin Rex wrote: > > - It requires hostbased service names plus mutual authentication, > > altough the majority of gssapi mechanism does not implement > > hostbased service names and a significant fraction of > > "simple" gssapi mechanisms doesn't provide acceptor-to-initiator > > authentication at all. >=20 > Where is the acceptor-to-initiator introduced here? The FXA-TLS ID says "the client MUST request mutual authentication" and continues with "MUST fail if not available", and this is where it obviously introduces the "acceptor-to-initiator" authentication. GSS-API traditionally implied initiator-to-acceptor authentication. When the initiator requests "mutual authentication", it is actually a request for "acceptor-to-initiator" authentication. The "acceptor-to-initiator only" authentication, which is what is commonly used by Web-Browsers with HTTPS these days would be GSS-API with anonymous client credentials requesting mutual authentication Anonymous (initiator) credentials are not very well-defined and supported by very few gssapi mechanisms these days). Anonymous acceptor credentials are somewhat more common, they're required for gssapi mechanisms that are unable to perform acceptor-to-initiator authentication, e.g. challenge-response mechanisms like NTLM. So the mutual flag is somewhat of a misnomer, witnessing that originally one didn't think about mechanisms where the client would not be authenticated. >=20 > >- It requires the brand-new optional extension "GSS_Pseudo_random" > > from a gss-api mechanism, which the majority of existing > > mechanism do not implement, and which can not be provided > > by a significant fraction of gss-api mechanisms that do > > not provide confidentiality protection and is impossible to > > provide by authentication-only mechanisms. >=20 > I beg to disagree on this. The FXA-TLS ID defines a generic and > extensible mechanism to allow=20 > the use of off-shelf GSS-API libraries, but it does not encourage the > use of arbitrary GSS-API mechanism for the TLS handshake. > Apps will pick and choose which GSS-API mechanism to support. >=20 > This is in analogy and consistent with the fact that how you choose to > negotiate the RFC4279 PSK cipher suites. This differs from RFC4279 in > that using RFC4279 you do not authenticate the server other than to the > extend that the server knows the shared key and that key may be shared > among multiple services on the server host. PSK cipher suites are already a big prerequisite and significant unnecessary burden. I would prefer an extension approach that could be built with minor modifications to an existing SSLv3-only stack in a small amount of time, using only the available SSL ciphersuites. >=20 > The GSS PRF is designed to be very light-weighted to be implemented. > Most existing GSS-API already have implemented it one way or the other. > The PRF RFC is new, but it is not new at all to implementations. I'm not aware that there is a generic GSS PRF spec. I know there is one for Kerberos, and that some people confuse GSS-API with Kerberos. Implementors of SPKM (rfc-2025) will first have to standardize on a prf before they can implement it, which is a HUGE burden. >=20 > >- it performs the gssapi handshake in the clear before the > > TLS encryption applied. It would be much better if the > > GSS-API authentication is performed within a tunnel that > > is already TLS-protected, so that the cryptographic > > strength of both add up for network-level attacks. >=20 > If an GSS-API mechanism cannot work without TLS protection, it should > NOT be selected according to this draft. I didn't say that it can not work without, just that the security level of the GSS-API mechanism itself is marginal at best when compared to TLS. I think that a protocol providing a standardized GSS-API authentication for a TLS-protected communication channel should not discriminate against or preclude whole classes of gssapi mechanism -- if it did, it should not be considered for IETF standards track, because we certainly can do much better. > > Furthermore this draft does not > prevent the gss-api data from being protected by TLS. People want to do > that already do it. It is just not within the scope of this draft.=20 It unecessarily puts the authentication exchange into the cleartext section of the TLS handshake. We already know that this is considered a problem for the client certificate message in the existing SSL/TLS handshake, why should we repeat this known mistake when it can be easily avoided? >=20 > This draft wants to move the GSS-API down to the TLS stack. This way all > upper layer protocols would benefit from it automatically if it is > chosen based on the negotiation layer. I'm all for layering protocol stacks. However I totally disagree about the layering sequence. I firmly believe that the GSS-API implementation should be called by a communication layer on top of regular TLS, and provide a TLS-with-added-value, instead of a forced marriage as required for FXA-TLS and its predecessor proposal. >=20 >=20 > > Recent TLS implementations provide fairly strong protection, > > and to make use of any TLS extension in this area, a new TLS > > implementation will be required. The involved GSS-API mechanism > > will almost always be legacy, and fairly weak in comparison to > > a recent TLS. >=20 > Can you provide a concrete example? And we can analyze that if you do. I > do not have an example myself, but I can envision similar advances would > have to be made into Kerberos, and we do not lose the protection > end-to-end in such situations. Integrating GSS with TLS gives us the > most economical way to innovate and reduce the proliferation of > mechanisms. You should know pretty well. You're involved in the FAST-Armor vs. StartTLS discussion which addresses know weaknesses in specific authentication exchanges that are in common use and can not be easily abandoned. Many WindowsXPsp2 machines perform regular NTLM authentications these days because of a serious bug in the sp2 Kerberos.dll. (which is fixed by KB885887, but that Hotfix is still not publicly available and SP3 is delayed for whatever strategic reasons). >=20 > > Doing it in the fashion that Stefan is looking for means that one will > have to merge GSS-API and TLS with a sledge hammer, and will be > extremely >=20 > > difficult to impossible to adopt by very common environments that > terminate the SSL/TLS communication at the edge of a backend distributed > >=20 > > system(reverse proxies, SSL Accellerators as closed third-party boxes, > etc.) >=20 > Not all gss-api mechanisms are created equal. The TLS client need to > choose the GSS-API mechanism in the same way it need to select which set > of ciphersuites to support. This is a very consistent and time-proven > model. There is no one arguing for a plug-&-play model that allows the > plug-in of any GSS-API mechanism to TLS. There is significant interest in plug-n-play arbitrary gssapi mechanisms into a single gssapi multi-mechanism. Is it really that difficult to predict that people will want a choice of the gssapi mechanism that they use with TLS? The one thing that can be loaded off to (the) TLS (handshake) is the common gssapi mechanism selection (no optimistic token). But that could be done in a fairly generic black box fashion (independent of any particular gssapi mechanism/implementation). I consider the lack of support for virtual hosts in (base) SSL/TLSv1 an issue that should be addressed and solved by a GSS-API authentication for TLS standard. And it should be solved in a transparent fashion for TLS using a regular SSL server certs and TLS using GSS-API based server authentication. Very few GSS-API mechanisms allow for "automatic selection" of server credentials during gss_accept_sec_context(). Since the creation of credentials is EXPLICITLY made a local issue of an implementation, no standard based on GSS-API should make an assumption as to whether a gssapi mechanism can automatically determine and correctly acquire a matching server credential when gss_accept_sec_context is called with GSS_C_NO_CREDENTIAL. In fact, most gssapi mechanism implementation are not able to do this. >=20 > I would like to request to have meaningful technical discussions before > making a conclusion prematurely.=20 >=20 > >=20 > The scenarios for securing TLS using Kerberos are very compelling, and > this draft provides the simplest way to provide a secure solution that > the industry badly need. The industry will do it with or without IETF. I thought this is about authentication a secure TLS channel using a GSS-API mechanis. I agree that such a possibility would be greatly appreciated. We currently have the situation that we can use GSS-API based Single Sign-On with our legacy frontends, but not with the HTTP-based newer frontends. Right now, single sign-on is only possible if the GSS-API based Single Sign-On is based on PKI (i.e. SPKM-like) with X.509 certs and offers a possibility to furnish the browser with either the PKI credentials or a PKCS#11 access to these credentials. The possibility to offer GSS-API based authentication for the HTTP-based access as well would be great, but in order to support that on our backends, we would need an approach which flies with NO CHANGES whatsoever to an existing GSS-API mechanism and EXTREMELY low impact changes to an exiting SSLv3 implementation... >=20 > If IETF wants to stay relevant in today's fast paced world, it should > not delay the process and work out a solution that is consistent with > the IETF framework. The current process is simply not acceptable and > completely violates the IETF tenet. >=20 > We are already at a level of complexity where dirty hacks will create HUGE problems already in the short run. There are no such things as homogeneous environments. And even the homogeneous new installations that your seem to have in mind are going to the the heterogeneous environments of tomorrow, when a new feature or scheme comes up that people what to use (and for which they need a migration path). If we get smooth cooperation of GSS-API based and traditional certificate-based Server authentication this time around, this will likely reduce the pain and suffering for the next transition. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 17 19:19:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAwKC-0005Wp-6v; Tue, 17 Jul 2007 19:19:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAwKB-0005Rz-5T for tls@lists.ietf.org; Tue, 17 Jul 2007 19:19:23 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAwK9-0002kp-Ql for tls@lists.ietf.org; Tue, 17 Jul 2007 19:19:23 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id BAA13299 for ; Wed, 18 Jul 2007 01:19:20 +0200 (MESZ) From: Martin Rex Message-Id: <200707172319.l6HNJKrL007394@fs4113.wdf.sap.corp> Subject: Re: [TLS] GSS based PSK-TLS Orig-To: lzhu@windows.microsoft.com (Larry Zhu) To: tls@lists.ietf.org Cc: tls@lists.ietf.org Date: Wed, 18 Jul 2007 01:17:33 +0200 (MEST) In-Reply-To: from "Larry Zhu" at Jul 17, 7 03:40:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Larry Zhu wrote: > > Martin Rex wrote: > > TLS session can be cached, resumed and forked. Although performance > > is an issue for a significant amount of our customers, the RSA-server- > > authentication in the SSL handshake is NOT normally an issue (it only > > becomes an issue if the SSL session cache is configured too small). > > This will continue to work. I would like to emphasize FKA-TLS is a > variant of PSK-TLS. With the current proposal this will be pretty difficult and awkward. > > > GSS-API security context can not be cached and not be resumed. > > you do not need to resume in the GSS level. You can resume in the > PSK-TLS level. Again, this is a variant of PSK-TLS, you have all the > bells and whistlers of PSK-TLS. As soon as you say GSS-API, a lot of unsaid things become an issue which the current draft does not address at all, and which create huge architectural problems (for the TLS implementation). - GSS-API naming - GSS-API extensions, like authorization (Microsoft will likely want impersonation to work) persitence of GSS-API objects and attributes and access to such attributes (currently existing as well as future defined ones) With the proposed architecture FKA-TLS bolts GSS-API deep into the TLS (protocol) stack, and in order to make anything besides an "authentication succeded" boolean available to the calling application, you will have to hack up the TLS API in a massive way to make the underlying GSS-API accessible and session caching interoperate smoothly with GSS-API related feature requests and expectations of the calling application. Compare this to an architecture, where you have an almost vanilla TLS stack with support for a small "GSS-API mechanism list negotiation extension plus server name signalling" and one or more vanilla legacy GSS-API mechanisms bundled by an thin additional glue layer that combines this into a TLS-with-adjacent-GSSAPI-handshake, where you can plug'n'play gssapi mechanisms and TLS stacks. In such an architecture, you may still have to solve the GSS-API persistence in this additional top-level glue layer, but you can support close to any existing and conceivable GSS-API mechanism and the necessary changes to SSL/TLS are minimalistic and fully transparent/orthogonal to the evolution of the TLS protocol&stack (like addition of new ciphersuites). Not having to deal with GSS-API extensinos, objects, object persistence and naming within TLS will be by far the biggest advantage. Generating a self-signed RSA server certificate is trivial and a non-issue. Ignoring a self-signed RSA server certificate when the server is authenticated by GSS-API as well is trivial and a non-issue. Do NOT overestimate the security of the "endpoint identification" that Web-Browsers currently perform (EKR: I really appreciate your choice of terminology in rfc-2818). As I said before, the approach taken by SSH is much better, even without CA-signed host keys. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 17 21:00:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAxu3-0001CR-Hy; Tue, 17 Jul 2007 21:00:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAxu1-00012h-Od for tls@ietf.org; Tue, 17 Jul 2007 21:00:29 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAxu0-00053W-Hb for tls@ietf.org; Tue, 17 Jul 2007 21:00:29 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 17 Jul 2007 18:00:28 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.726.0; Tue, 17 Jul 2007 18:00:27 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jul 2007 18:00:27 -0700 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 Subject: RE: [TLS] GSS based PSK-TLS Date: Tue, 17 Jul 2007 18:00:20 -0700 Message-ID: In-Reply-To: <200707172141.l6HLfqU9000857@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] GSS based PSK-TLS Thread-Index: AcfIu1MBtrWytsHnQga/Cm3wjwUK3gAG6hkw References: from "Larry Zhu" at Jul 13, 7 04:46:12 pm <200707172141.l6HLfqU9000857@fs4113.wdf.sap.corp> From: Larry Zhu To: X-OriginalArrivalTime: 18 Jul 2007 01:00:27.0508 (UTC) FILETIME=[07A44B40:01C7C8D7] X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > With the current proposal this will be pretty difficult and awkward. Please elaborate. The FKA-TLS is a supper set of PSK-TLS, can you explain why a different way to establish the shared key would make it worse. > As soon as you say GSS-API, a lot of unsaid things become an issue=20 > which the current draft does not address at all, and which create huge > architectural problems (for the TLS implementation). I would like to understand what are the things unsaid. > - GSS-API naming This ID does not define additional naming. Any naming scheme would work. If there is the need to call out for a specific naming, please do tell. > - GSS-API extensions, like authorization > (Microsoft will likely want impersonation to work) > persitence of GSS-API objects and attributes and access to > such attributes (currently existing as well as future defined ones) What are those? If you have non-standard extensions, you will need to take care of it yourself. The draft will work with standard GSS-API operations. We envision it is sufficient with what is said in -03. > With the proposed architecture FKA-TLS bolts GSS-API deep into the TLS > (protocol) stack, and in order to make anything besides an=20 > "authentication succeded" boolean available to the calling=20 > application, you will have to hack up the TLS API in a massive way to=20 > make the underlying GSS-API accessible and session caching=20 > interoperate smoothly with GSS-API related feature requests and=20 > expectations of the calling application. What is the TLS API you are referring to here? > Compare this to an architecture, where you have an almost vanilla TLS=20 > stack with support for a small "GSS-API mechanism list negotiation=20 > extension plus server name signalling" and one or more vanilla legacy=20 > GSS-API mechanisms bundled by an thin additional glue layer that=20 > combines this into a TLS-with-adjacent-GSSAPI-handshake, > where you can plug'n'play gssapi mechanisms and TLS stacks. Let me reiterate that the ID does not encourage plug'n'play of GSS mechanisms. > In such an architecture, you may still have to solve the GSS-API=20 > persistence in this additional top-level glue layer, but you can=20 > support close to any existing and conceivable GSS-API mechanism and=20 > the necessary changes to SSL/TLS are minimalistic and fully=20 > transparent/orthogonal to the evolution of the TLS protocol&stack=20 > (like addition of new ciphersuites). Not having to deal with GSS-API=20 > extensinos, objects, object persistence and naming within TLS will be=20 > by far the biggest advantage. Let me reiterate that this ID does not encourage plug'n'play of GSS mechanisms. > Generating a self-signed RSA server certificate is trivial and a non-issue. It is hard to trust that cert and authenticate the server. This approach provides a high-scalable and robust solution without PKI. > Ignoring a self-signed RSA server certificate when the server is=20 > authenticated by GSS-API as well is trivial and a non-issue. This is an understatement. This approach pushes the solution down the stack. > Do NOT overestimate the security of the "endpoint identification" > that Web-Browsers currently perform (EKR: I really appreciate your=20 > choice of terminology in rfc-2818). As I said before, the approach=20 > taken by SSH is much better, even without CA-signed host keys. Please describe the problems and see if this ID can address them. --larry _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 12:18:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCEg-0000Bh-LX; Wed, 18 Jul 2007 12:18:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCEf-00009c-VM for tls@ietf.org; Wed, 18 Jul 2007 12:18:46 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBCEe-0006wq-Da for tls@ietf.org; Wed, 18 Jul 2007 12:18:45 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 2F7C03BF57; Wed, 18 Jul 2007 18:18:43 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13032-01-55; Wed, 18 Jul 2007 18:18:42 +0200 (CEST) Received: from [192.168.1.101] (c80-217-233-219.bredband.comhem.se [80.217.233.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id A3DEF3BF52; Wed, 18 Jul 2007 18:18:42 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <361B6F7E-C99C-469B-9234-A0C4F4D2CD55@it.su.se> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating Kerberos with TLS: draft-santesson-tls-gssapi Date: Wed, 18 Jul 2007 18:18:33 +0200 To: Larry Zhu X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.055 tagged_above=-99 required=7 tests=[AWL=0.257, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Comment on the draft draft-santesson-tls-gssapi-03.txt - An important goal to meet is enabling use of authentication infrastructure of the GSS mech for server and client authenticiation. When using gss server authentication, thers shold be no need to have a certificate on the server. - Feedback of key-data from the GSS-MECH back into the tls statemachine. GSS-API is more then a glorified OTP/password system, it provides key material that should be used, this solves problems like replay attacks w/o the need for a replay cache, etc. - I would prefer having both the ability to run gssapi in clear and inside a DH protected tls connection. But it should run inside TLS and not the application layer. I.e., not http negotiate yet again. Saying that all gss mechs are cryptographicly weak is wrong, saying they are strong are also wrong. Should provide both, or just define cryptographicly weak gss-mechs as out of scope for this solution. Defining a solution that only uses the weak mech's functionally seems, well, weird and quite unfriendly. - If its required to have DN for authorisation, well have the gss-mech define that then. I really don't like how everytime naming get up, its assumed that TLS naming today accully works, how many apps actually does correct authorisation with tls certificate based naming today, and why should they work with gss-style names ? This proposed solutions fixes 1, 2, 3, and 4. But thats becase I think weak gss mechs should be thrown out the window. Saying SPKM doesn't support gss-psudeo random is just silly, SPKM doesn't support anything, its not implementable and I want better security then des/rc2. Love 17 jul 2007 kl. 05.27 skrev Larry Zhu: > As we know -02 was published and it integrates Kerberos-alike GSS > mechanisms with TLS by importing the GSS key as PSK. It does so to > minimize the impact to the TLS state machine. > > > http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt > > > EKR requested us to nail down the use cases for this protocol and > explain the rational for the integration. > > In response, the ID revision -03 contains the use cases and why we > want > to integrate Kerberos with TLS, particularly in the introduction > section. > > http://www.secure-endpoints.com/tls-gss/draft-santesson-tls- > gssapi-03.tx > t > > The flowing document based on email posted by Larry Zhu describes > additional background information for the protocol design. > > http://www.secure-endpoints.com/tls-gss/fka-tls.txt > > thanks, > > --larry > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 12:42:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCbH-0003v9-BM; Wed, 18 Jul 2007 12:42:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCbF-0003lK-Pu for tls@ietf.org; Wed, 18 Jul 2007 12:42:05 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBCbD-0007V2-Sf for tls@ietf.org; Wed, 18 Jul 2007 12:42:05 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Wed, 18 Jul 2007 09:42:03 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.726.0; Wed, 18 Jul 2007 09:42:02 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jul 2007 09:42:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating Kerberos with TLS: draft-santesson-tls-gssapi Date: Wed, 18 Jul 2007 09:41:49 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] the use cases for GSS-based TLS and the plea for integrating Kerberos with TLS: draft-santesson-tls-gssapi Thread-Index: AcfJV1cgvZEhnOLfQgeKwyn+58k1JgAAixun References: <361B6F7E-C99C-469B-9234-A0C4F4D2CD55@it.su.se> From: Larry Zhu To: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= X-OriginalArrivalTime: 18 Jul 2007 16:42:02.0446 (UTC) FILETIME=[913FB6E0:01C7C95A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0726811478==" Errors-To: tls-bounces@lists.ietf.org --===============0726811478== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C95A.89B6E619" ------_=_NextPart_001_01C7C95A.89B6E619 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Love H=F6rnquist =C5strand wrote: > - I would prefer having both the ability to run gssapi in clear and > inside a DH protected tls connection.=20 =20 In fact you have this ability in draft -02/-03. =20 the protocol defined in this draft is generic and extensible, such that = you can build the DH protection logic into the GSS-mechanism to encrypt = GSS-API data for the real mechanism such as digest.=20 =20 even better, you do not need to do that for every real GSS-API = mechanism, instead, you can define a stackable protection GSS-mechanism = like SPNEGO, and use that to protect for the real GSS-API mechanisms. =20 do you agree? =20 --larry ________________________________ From: Love H=F6rnquist =C5strand [mailto:lha@it.su.se] Sent: Wed 7/18/2007 9:18 AM To: Larry Zhu Cc: tls@ietf.org Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for = integrating Kerberos with TLS: draft-santesson-tls-gssapi Comment on the draft draft-santesson-tls-gssapi-03.txt - An important goal to meet is enabling use of authentication infrastructure of the GSS mech for server and client authenticiation. When using gss server authentication, thers shold be no need to have a certificate on the server. - Feedback of key-data from the GSS-MECH back into the tls statemachine. GSS-API is more then a glorified OTP/password system, it provides key material that should be used, this solves problems like replay attacks w/o the need for a replay cache, etc. - I would prefer having both the ability to run gssapi in clear and inside a DH protected tls connection. But it should run inside TLS and not the application layer. I.e., not http negotiate yet again. Saying that all gss mechs are cryptographicly weak is wrong, saying they are strong are also wrong. Should provide both, or just define cryptographicly weak gss-mechs as out of scope for this solution. Defining a solution that only uses the weak mech's functionally seems, well, weird and quite unfriendly. - If its required to have DN for authorisation, well have the gss-mech define that then. I really don't like how everytime naming get up, its assumed that TLS naming today accully works, how many apps actually does correct authorisation with tls certificate based naming today, and why should they work with gss-style names ? This proposed solutions fixes 1, 2, 3, and 4. But thats becase I think weak gss mechs should be thrown out the window. Saying SPKM doesn't support gss-psudeo random is just silly, SPKM doesn't support anything, its not implementable and I want better security then des/rc2. Love 17 jul 2007 kl. 05.27 skrev Larry Zhu: > As we know -02 was published and it integrates Kerberos-alike GSS > mechanisms with TLS by importing the GSS key as PSK. It does so to > minimize the impact to the TLS state machine. > > > http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt > > > EKR requested us to nail down the use cases for this protocol and > explain the rational for the integration. > > In response, the ID revision -03 contains the use cases and why we=20 > want > to integrate Kerberos with TLS, particularly in the introduction > section. > > http://www.secure-endpoints.com/tls-gss/draft-santesson-tls- > gssapi-03.tx > t > > The flowing document based on email posted by Larry Zhu describes > additional background information for the protocol design. > > http://www.secure-endpoints.com/tls-gss/fka-tls.txt > > thanks, > > --larry > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls ------_=_NextPart_001_01C7C95A.89B6E619 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TLS] the use cases for GSS-based TLS = and the plea for integrating Kerberos with TLS: = draft-santesson-tls-gssapi=0A= =0A= =0A= =0A=
=0A=
=0A=

Love = H=F6rnquist =C5strand wrote:

=0A=

> - I would prefer having both the ability to run gssapi in = clear and
>   inside a DH protected tls connection. =

=0A=

 

=0A=

In = fact you have this ability in draft -02/-03.

=0A=

 

=0A=

 the protocol defined in this draft is generic and = extensible, such that you can build the DH protection logic into = the GSS-mechanism to encrypt GSS-API data for the real mechanism such as = digest.

=0A=

 

=0A=

even = better, you do not need to do that for every real GSS-API mechanism, = instead, you can define a stackable protection GSS-mechanism like = SPNEGO, and use that to protect for the real GSS-API = mechanisms.

=0A=

 

=0A=

do you = agree?

=0A=

 

=0A=

--larry

=0A=

=0A=
=0A= From: Love H=F6rnquist =C5strand = [mailto:lha@it.su.se]
Sent: Wed 7/18/2007 9:18 = AM
To: Larry Zhu
Cc: tls@ietf.org
Subject: = Re: [TLS] the use cases for GSS-based TLS and the plea for integrating = Kerberos with TLS: draft-santesson-tls-gssapi

=0A=
=0A=

Comment on the draft = draft-santesson-tls-gssapi-03.txt

- An important goal to meet is = enabling use of authentication
   infrastructure of the GSS = mech for server and client
   authenticiation. When using = gss server authentication, thers shold
   be no need to = have a certificate on the server.

- Feedback of key-data from the = GSS-MECH back into the tls
   statemachine. GSS-API is more = then a glorified OTP/password system,
   it provides key = material that should be used, this solves problems
   like = replay attacks w/o the need for a replay cache, etc.

- I would = prefer having both the ability to run gssapi in clear = and
   inside a DH protected tls connection. But it should = run inside TLS
   and not the application layer. I.e., not = http negotiate yet again.
   Saying that all gss mechs are = cryptographicly weak is wrong, saying
   they are strong = are also wrong. Should provide both, or just define
   = cryptographicly weak gss-mechs as out of scope for this
   = solution. Defining a solution that only uses the weak = mech's
   functionally seems, well, weird and quite = unfriendly.

- If its required to have DN for authorisation, well = have the gss-mech
   define that then. I really don't like = how everytime naming get up,
   its assumed that TLS naming = today accully works, how many apps
   actually does correct = authorisation with tls certificate based
   naming today, = and why should they work with gss-style names ?

This proposed = solutions fixes 1, 2, 3, and 4. But thats becase I
think weak gss = mechs should be thrown out the window.

Saying SPKM doesn't = support gss-psudeo random is just silly,
SPKM doesn't support = anything, its not implementable and
I want better security then = des/rc2.

Love


17 jul 2007 kl. 05.27 skrev Larry = Zhu:

> As we know -02 was published and it integrates = Kerberos-alike GSS
> mechanisms with TLS by importing the GSS key = as PSK. It does so to
> minimize the impact to the TLS state = machine.
>
>
> http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.t= xt
>
>
> EKR requested us to nail down the use = cases for this protocol and
> explain the rational for the = integration.
>
> In response, the ID revision -03 contains = the use cases and why we 
> want
> to integrate = Kerberos with TLS, particularly in the introduction
> = section.
>
> htt= p://www.secure-endpoints.com/tls-gss/draft-santesson-tls-
> = gssapi-03.tx
> t
>
> The flowing document based on = email posted by Larry Zhu describes
> additional background = information for the protocol design.
>
> http://www.s= ecure-endpoints.com/tls-gss/fka-tls.txt
>
> = thanks,
>
> --larry
>
>
>
> = _______________________________________________
> TLS mailing = list
> TLS@lists.ietf.org
> https://www1.ietf.org= /mailman/listinfo/tls


------_=_NextPart_001_01C7C95A.89B6E619-- --===============0726811478== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0726811478==-- From tls-bounces@lists.ietf.org Wed Jul 18 12:52:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCky-0008Dh-Ss; Wed, 18 Jul 2007 12:52:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCky-0008Db-B5 for tls@ietf.org; Wed, 18 Jul 2007 12:52:08 -0400 Received: from smtp1.su.se ([130.237.162.112]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBCkw-0007je-N1 for tls@ietf.org; Wed, 18 Jul 2007 12:52:08 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id A186E741B3; Wed, 18 Jul 2007 18:52:05 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29268-01-6; Wed, 18 Jul 2007 18:52:04 +0200 (CEST) Received: from [192.168.1.101] (c80-217-233-219.bredband.comhem.se [80.217.233.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id CB855740DC; Wed, 18 Jul 2007 18:52:04 +0200 (CEST) In-Reply-To: References: <361B6F7E-C99C-469B-9234-A0C4F4D2CD55@it.su.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating Kerberos with TLS: draft-santesson-tls-gssapi Date: Wed, 18 Jul 2007 18:51:54 +0200 To: Larry Zhu X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.954 tagged_above=-99 required=7 tests=[AWL=0.358, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org 18 jul 2007 kl. 18.41 skrev Larry Zhu: > Love H=F6rnquist =C5strand wrote: > > - I would prefer having both the ability to run gssapi in clear and > > inside a DH protected tls connection. > > In fact you have this ability in draft -02/-03. > > the protocol defined in this draft is generic and extensible, such =20= > that you can build the DH protection logic into the GSS-mechanism =20 > to encrypt GSS-API data for the real mechanism such as digest. > > even better, you do not need to do that for every real GSS-API =20 > mechanism, instead, you can define a stackable protection GSS-=20 > mechanism like SPNEGO, and use that to protect for the real GSS-API =20= > mechanisms. > > do you agree? No. If the gss mech is weak and needs dh/rsa, may it should a requirement =20= to have use server certificates. I'm tired of sprinkling DH everywhere. Love > > --larry > > From: Love H=F6rnquist =C5strand [mailto:lha@it.su.se] > Sent: Wed 7/18/2007 9:18 AM > To: Larry Zhu > Cc: tls@ietf.org > Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for =20= > integrating Kerberos with TLS: draft-santesson-tls-gssapi > > Comment on the draft draft-santesson-tls-gssapi-03.txt > > - An important goal to meet is enabling use of authentication > infrastructure of the GSS mech for server and client > authenticiation. When using gss server authentication, thers shold > be no need to have a certificate on the server. > > - Feedback of key-data from the GSS-MECH back into the tls > statemachine. GSS-API is more then a glorified OTP/password system, > it provides key material that should be used, this solves problems > like replay attacks w/o the need for a replay cache, etc. > > - I would prefer having both the ability to run gssapi in clear and > inside a DH protected tls connection. But it should run inside TLS > and not the application layer. I.e., not http negotiate yet again. > Saying that all gss mechs are cryptographicly weak is wrong, saying > they are strong are also wrong. Should provide both, or just define > cryptographicly weak gss-mechs as out of scope for this > solution. Defining a solution that only uses the weak mech's > functionally seems, well, weird and quite unfriendly. > > - If its required to have DN for authorisation, well have the gss-mech > define that then. I really don't like how everytime naming get up, > its assumed that TLS naming today accully works, how many apps > actually does correct authorisation with tls certificate based > naming today, and why should they work with gss-style names ? > > This proposed solutions fixes 1, 2, 3, and 4. But thats becase I > think weak gss mechs should be thrown out the window. > > Saying SPKM doesn't support gss-psudeo random is just silly, > SPKM doesn't support anything, its not implementable and > I want better security then des/rc2. > > Love > > > 17 jul 2007 kl. 05.27 skrev Larry Zhu: > > > As we know -02 was published and it integrates Kerberos-alike GSS > > mechanisms with TLS by importing the GSS key as PSK. It does so to > > minimize the impact to the TLS state machine. > > > > > > http://www.ietf.org/internet-drafts/draft-santesson-tls-=20 > gssapi-02.txt > > > > > > EKR requested us to nail down the use cases for this protocol and > > explain the rational for the integration. > > > > In response, the ID revision -03 contains the use cases and why we > > want > > to integrate Kerberos with TLS, particularly in the introduction > > section. > > > > http://www.secure-endpoints.com/tls-gss/draft-santesson-tls- > > gssapi-03.tx > > t > > > > The flowing document based on email posted by Larry Zhu describes > > additional background information for the protocol design. > > > > http://www.secure-endpoints.com/tls-gss/fka-tls.txt > > > > thanks, > > > > --larry > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls > > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 14:24:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBECI-0000nu-TB; Wed, 18 Jul 2007 14:24:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBECG-0000mV-Fy for tls@ietf.org; Wed, 18 Jul 2007 14:24:24 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBECF-0000ym-LH for tls@ietf.org; Wed, 18 Jul 2007 14:24:24 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id UAA16398; Wed, 18 Jul 2007 20:24:17 +0200 (MESZ) From: Martin Rex Message-Id: <200707181824.l6IIOItm018779@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for To: lha@it.su.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Wed, 18 Jul 2007 20:24:18 +0200 (MEST) In-Reply-To: <361B6F7E-C99C-469B-9234-A0C4F4D2CD55@it.su.se> from "=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=" at Jul 18, 7 06:18:33 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= wrote: > > Comment on the draft draft-santesson-tls-gssapi-03.txt > > - An important goal to meet is enabling use of authentication > infrastructure of the GSS mech for server and client > authenticiation. When using gss server authentication, thers shold > be no need to have a certificate on the server. I agree that there should NOT be a need for a fully configured PKI. I completely disagree on the absense of a Certificate-based server credential. A fallback self-signed cert is a no-brainer. Do you seriously propose to give up on a mandatory-to-implement authentication scheme that will provide interoperability when your locally-preferred authentication scheme (GSS-API) is unavailable. SSL started off with mandatory to implement ciphersuites in order to provide interoperability, and historically, these used a certificate-based credential. > > - Feedback of key-data from the GSS-MECH back into the tls > statemachine. GSS-API is more then a glorified OTP/password system, > it provides key material that should be used, this solves problems > like replay attacks w/o the need for a replay cache, etc. Do you know of a weakness in TLS that we don't, or what is your rationale for this. As I already described, the majority of GSS-API mechanisms doesn't have gss_prf and for an entire classes of GSS-API mechanism it is impossible to provide keying material or gss_prf. In order to mix GSS-API-based keying material into the TLS key exchange you will have to MESS severely with TLS internals. Unless you can show that TLS key establishment is weak or broken, such messing around with TLS internal is a pretty bad idea -- and even if you could show -- we should rather fix TLS instead of messing with the TLS key exchange. First of all, the GSS-API mechanism should protect against replay attacks all by itself. Where that is insufficient, the additional use of GSS-API channel bindings should do the trick. At a first glance, the use of the SSL session ID should be sufficient. (unless the SSL/TLS stack uses a really braindead algorithm to generate SSL session IDs.) > > - I would prefer having both the ability to run gssapi in clear and > inside a DH protected tls connection. But it should run inside TLS > and not the application layer. I.e., not http negotiate yet again. > Saying that all gss mechs are cryptographicly weak is wrong, saying > they are strong are also wrong. Should provide both, or just define > cryptographicly weak gss-mechs as out of scope for this > solution. Defining a solution that only uses the weak mech's > functionally seems, well, weird and quite unfriendly. There is a substantial security benefit in being able to perform the GSS-API authentication under TLS encryption, namely to protect the identity of the client from network-level sniffing. We have heard repeated request for protection of the SSL client cert, which unfortunately travels in the cleartext portion of the SSL handshake (probably in an attempt to simplify the SSL state machine to make the encrypted part of a full handshake and the encrypted part of a session resume alike). Can you provide any technical reasons why a solution should provide for GSS-API authentication in the cleartext part of the communication? "I like it" and "it's easier for me to read network traces" do not describe convincing technical benefits. > > - If its required to have DN for authorisation, well have the gss-mech > define that then. I really don't like how everytime naming get up, > its assumed that TLS naming today accully works, how many apps > actually does correct authorisation with tls certificate based > naming today, and why should they work with gss-style names ? Actually, TLS does NOT do naming at all. That has been explicit in the specs from the beginning. The details of the authentication process is outside of the scope of TLS and must be addressed by communication protocols built on top of TLS (like HTTP over SSL/TLS). The document under discussion breaks with this tradition in a pretty bad and totally unnecessary fashion. > > This proposed solutions fixes 1, 2, 3, and 4. But thats becase I > think weak gss mechs should be thrown out the window. The strength of a cryptographic protocol wears off (quickly) over time. This is one of the reasons why I would greatly prefer an approach orthogonal to the TLS protocol engine. If you do the GSS-API handshake after the TLS handshake, under TLS protection, using the SSL Record protocol and probably with a different "container tag" than regular application data (so no-one will confuse it with application data), then improvements to TLS (like new and stronger ciphersuites) can be used as soon as they become available, entirely independent of the inner GSS-API authentication and without having to update the gssapi-over-tls specification. > > Saying SPKM doesn't support gss-psudeo random is just silly, > SPKM doesn't support anything, its not implementable and > I want better security then des/rc2. You seem to confuse the mandatory to implement symmetric ciphers in rfc-2025 with the stuff that really gets used in productive deployments. About 6 different vendors have certified for interoperability with our application with SPKM-based gssapi mechanisms and 4 more with SPKM-like mechanisms. Doing this costs them real money, and they wouldn't have done it when there weren't any of our customers using these third-party products and paying for it. As I've been saying before the big advantage of the PKI-based gssapi mechanisms for Single Sign-On is, that it is possible to share the credentials with the Web-Browser and re-use Single Sign-On between off-the-shelf Web-Browsers and off-the-shelf Web-Servers already today. We've been doing this on company-wide scale for the last 6 years. I'm getting the impression that it might be much easier for me to write an I-D with a well-designed proposal than to continue bashing on draft-santesson-tls-gssapi-03.txt But I'm not a TLS expert (I only have been doing support and some improvements the last 6 years for an OEM library that we ship), and would need help/advice on how to add the extension with the least possible impact the maximum orthogonality to the TLS architecture (in order to continuously benefit from TLS evolution). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 14:46:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEXV-0005Zi-By; Wed, 18 Jul 2007 14:46:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEXR-0005XJ-3t for tls@ietf.org; Wed, 18 Jul 2007 14:46:17 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBEXQ-0002qz-Fx for tls@ietf.org; Wed, 18 Jul 2007 14:46:17 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id UAA14183; Wed, 18 Jul 2007 20:46:11 +0200 (MESZ) From: Martin Rex Message-Id: <200707181846.l6IIkBCp020321@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for To: lzhu@windows.microsoft.com (Larry Zhu) Date: Wed, 18 Jul 2007 20:46:11 +0200 (MEST) In-Reply-To: from "Larry Zhu" at Jul 18, 7 09:41:49 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Larry Zhu wrote: > > even better, you do not need to do that for every real GSS-API > mechanism, instead, you can define a stackable protection > GSS-mechanism like SPNEGO, and use that to protect for the > real GSS-API mechanisms. Ouch. With a simple mechanism (OID) negotiation logic within a Hello extension, we could get rid of SPNEGO entirely for gssapi-tls. This would have many advantages: - when the common mechanism OID selection is built into a TLS extension, then TLS can simply perform the regular SSL handshake when no common mechanism is available. - it completely avoids the entire SPNEGO codebase. a large part of the installed base of GSS-API mechanism doesn't have SPNEGO, and as I've said, we would have compelling use cases if the scheme would work with the existing installed base (of gssapi mechanisms) and without SPNEGO and minimalistic changes to SSL/TLS. Changes to the Web-Browsers and Web-Servers are necessary, of course, but with such a low-impact change as I have been describing throughout my last postings, the necessary small changes for Browsers like Firefox and TLS implementations would come within a few weeks. And I would give this a much better chance to get implemented into our backends and SSL - and additional multi-mechanism glue layer would be entirely unnecessary in this scenario. A server or browser could simply load and use the negotiated GSS-API mechanism directly. Btw. thinking about the security context establishment of GSS-API: there is no size limit on the context-level tokens within GSS-API. Although a single SSL Record of 16K would be sufficient for the majority of environments (gss-api mechanisms) that I have seen, extensive use of X.509v3 extensions (attributes,constraints,policies, URLs,disclaimers,digital-junkyard-of-your-favorite-CA) as well as PACs or similar bloat in Kerberos certificates might exceed 16K. so a simple framing protocol for the gssapi context level tokens might be needed. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 15:52:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFZA-0002n8-NY; Wed, 18 Jul 2007 15:52:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFZ9-0002mc-6d for tls@ietf.org; Wed, 18 Jul 2007 15:52:07 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBFZ8-0004ru-6C for tls@ietf.org; Wed, 18 Jul 2007 15:52:07 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Wed, 18 Jul 2007 12:52:05 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.726.0; Wed, 18 Jul 2007 12:52:05 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jul 2007 12:52:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for Date: Wed, 18 Jul 2007 12:51:20 -0700 Message-ID: In-Reply-To: <200707181824.l6IIOItm018779@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] the use cases for GSS-based TLS and the plea for Thread-Index: AcfJaOO/oJA5kq0tSrS3XQo+Df85wwAC03jA References: =?iso-8859-1?Q?=3C361B6F7E-C99C-469B-9234-A0C4F4D2CD55=40it=2Esu=2Ese=3E_?= =?iso-8859-1?Q?from_=22Love_H=F6rnquist_=C5strand=22_at_Jul_18=2C_7_06=3A?= =?iso-8859-1?Q?18=3A33_pm_=3C200707181824=2El6IIOItm018779=40fs4113=2Ew?= =?iso-8859-1?Q?df=2Esap=2Ecorp=3E?= From: Larry Zhu To: , =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= X-OriginalArrivalTime: 18 Jul 2007 19:52:04.0857 (UTC) FILETIME=[1D9D8E90:01C7C975] X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > I'm getting the impression that it might be much easier for me > to write an I-D with a well-designed proposal than to continue > bashing on draft-santesson-tls-gssapi-03.txt This sounds very constructive and promising.=20 I am happy that you support the work. =20 Instead of writing a separate draft, you can update the ID with your = proposal, unless you have a complete different beast. We do not need to = have two different proposals doing the same thing if we can agree with = the proposal you are making. =20 I am very pleased that we are making progress on this now.=20 In the meanwhile, I would like to have more reviewers commenting on this = effort. Please tell us what you think. Thanks, --larry -----Original Message----- From: Martin Rex [mailto:Martin.Rex@sap.com]=20 Sent: Wednesday, July 18, 2007 11:24 AM To: Love H=F6rnquist =C5strand Cc: Larry Zhu; tls@ietf.org Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for =3D?ISO-8859-1?Q?Love_H=3DF6rnquist_=3DC5strand?=3D wrote: >=20 > Comment on the draft draft-santesson-tls-gssapi-03.txt >=20 > - An important goal to meet is enabling use of authentication > infrastructure of the GSS mech for server and client > authenticiation. When using gss server authentication, thers shold > be no need to have a certificate on the server. I agree that there should NOT be a need for a fully configured PKI. I completely disagree on the absense of a Certificate-based server credential. A fallback self-signed cert is a no-brainer.=20 Do you seriously propose to give up on a mandatory-to-implement authentication scheme that will provide interoperability when your locally-preferred authentication scheme (GSS-API) is unavailable. SSL started off with mandatory to implement ciphersuites in order to provide interoperability, and historically, these used a certificate-based credential. >=20 > - Feedback of key-data from the GSS-MECH back into the tls > statemachine. GSS-API is more then a glorified OTP/password system, > it provides key material that should be used, this solves problems > like replay attacks w/o the need for a replay cache, etc. Do you know of a weakness in TLS that we don't, or what is your rationale for this. As I already described, the majority of GSS-API mechanisms doesn't have gss_prf and for an entire classes of GSS-API mechanism it is impossible to provide keying material or gss_prf. In order to mix GSS-API-based keying material into the TLS key exchange you will have to MESS severely with TLS internals. Unless you can show that TLS key establishment is weak or broken, such messing around with TLS internal is a pretty bad idea -- and even if you could show -- we should rather fix TLS instead of messing with the TLS key exchange. First of all, the GSS-API mechanism should protect against replay attacks all by itself. Where that is insufficient, the additional use of GSS-API channel bindings should do the trick. At a first glance, the use of the SSL session ID should be sufficient. (unless the SSL/TLS stack uses a really braindead algorithm to generate SSL session IDs.) >=20 > - I would prefer having both the ability to run gssapi in clear and > inside a DH protected tls connection. But it should run inside TLS > and not the application layer. I.e., not http negotiate yet again. > Saying that all gss mechs are cryptographicly weak is wrong, saying > they are strong are also wrong. Should provide both, or just define > cryptographicly weak gss-mechs as out of scope for this > solution. Defining a solution that only uses the weak mech's > functionally seems, well, weird and quite unfriendly. There is a substantial security benefit in being able to perform the GSS-API authentication under TLS encryption, namely to protect the identity of the client from network-level sniffing. We have heard repeated request for protection of the SSL client cert, which unfortunately travels in the cleartext portion of the SSL handshake (probably in an attempt to simplify the SSL state machine to make the encrypted part of a full handshake and the encrypted part of a session resume alike). Can you provide any technical reasons why a solution should provide for GSS-API authentication in the cleartext part of the communication? "I like it" and "it's easier for me to read network traces" do not = describe convincing technical benefits. >=20 > - If its required to have DN for authorisation, well have the gss-mech > define that then. I really don't like how everytime naming get up, > its assumed that TLS naming today accully works, how many apps > actually does correct authorisation with tls certificate based > naming today, and why should they work with gss-style names ? Actually, TLS does NOT do naming at all. That has been explicit in the specs from the beginning. The details of the authentication process is outside of the scope of TLS and must be addressed by communication protocols built on top of TLS (like HTTP over SSL/TLS). The document under discussion breaks with this tradition in a pretty bad and totally unnecessary fashion.=20 >=20 > This proposed solutions fixes 1, 2, 3, and 4. But thats becase I > think weak gss mechs should be thrown out the window. The strength of a cryptographic protocol wears off (quickly) over time. = This is one of the reasons why I would greatly prefer an approach orthogonal to the TLS protocol engine. If you do the GSS-API handshake after the TLS handshake, under TLS protection, using the SSL Record protocol and probably with a different "container tag" than regular application data (so no-one will confuse it with application data), then improvements to TLS (like new and stronger ciphersuites) can be used as soon as they become available, entirely independent of the inner GSS-API authentication and without having to update the gssapi-over-tls specification.=20 >=20 > Saying SPKM doesn't support gss-psudeo random is just silly, > SPKM doesn't support anything, its not implementable and > I want better security then des/rc2. You seem to confuse the mandatory to implement symmetric ciphers in rfc-2025 with the stuff that really gets used in productive deployments. About 6 different vendors have certified for interoperability with our application with SPKM-based gssapi mechanisms and 4 more with SPKM-like mechanisms. Doing this costs them real money, and they wouldn't have done it when there weren't any of our customers using these third-party products and paying for it. As I've been saying before the big advantage of the PKI-based=20 gssapi mechanisms for Single Sign-On is, that it is possible to share the credentials with the Web-Browser and re-use Single Sign-On between off-the-shelf Web-Browsers and off-the-shelf Web-Servers already today. We've been doing this on company-wide scale for the last 6 years. I'm getting the impression that it might be much easier for me to write an I-D with a well-designed proposal than to continue bashing on draft-santesson-tls-gssapi-03.txt But I'm not a TLS expert (I only have been doing support and some improvements the last 6 years for an OEM library that we ship), and would need help/advice on how to add the extension with the least possible impact the maximum orthogonality to the TLS architecture (in order to continuously benefit from TLS evolution). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 18:56:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIRm-00036D-5x; Wed, 18 Jul 2007 18:56:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIRk-000362-Ky for tls@ietf.org; Wed, 18 Jul 2007 18:56:40 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBIRj-0000bB-9X for tls@ietf.org; Wed, 18 Jul 2007 18:56:40 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6IMucVD013068 for ; Wed, 18 Jul 2007 22:56:38 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6IMuccm025982 for ; Wed, 18 Jul 2007 16:56:38 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6IMuYRX025096 for ; Wed, 18 Jul 2007 17:56:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6IMuYPq025095 for tls@ietf.org; Wed, 18 Jul 2007 17:56:34 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 18 Jul 2007 17:56:34 -0500 From: Nicolas Williams To: tls@ietf.org Message-ID: <20070718225633.GR24645@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [TLS] Negotiation in draft-santesson-tls-gssapi X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org If this protocol will not provide a way for the server to tell the client what GSS-API mechanisms it supports or any other GSS-API mechanism negotiation facility then I think the server MUST support SPNEGO, else the client and server have to agree a priori on what mechs to use. Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 18:58:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBITY-00044U-Im; Wed, 18 Jul 2007 18:58:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBITW-00044M-Aw for tls@ietf.org; Wed, 18 Jul 2007 18:58:31 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBITW-0000dd-0M for tls@ietf.org; Wed, 18 Jul 2007 18:58:30 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Wed, 18 Jul 2007 15:58:29 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.726.0; Wed, 18 Jul 2007 15:58:27 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jul 2007 15:58:26 -0700 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 Subject: RE: [TLS] Negotiation in draft-santesson-tls-gssapi Date: Wed, 18 Jul 2007 15:57:37 -0700 Message-ID: In-Reply-To: <20070718225633.GR24645@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Negotiation in draft-santesson-tls-gssapi Thread-Index: AcfJjvZcfYosNd5XR521Uahl1BykfwAAAq6Q References: <20070718225633.GR24645@Sun.COM> From: Larry Zhu To: Nicolas Williams , X-OriginalArrivalTime: 18 Jul 2007 22:58:26.0586 (UTC) FILETIME=[2671FFA0:01C7C98F] X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I agree with the proposed the change. --larry -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Wednesday, July 18, 2007 3:57 PM To: tls@ietf.org Subject: [TLS] Negotiation in draft-santesson-tls-gssapi If this protocol will not provide a way for the server to tell the client what GSS-API mechanisms it supports or any other GSS-API mechanism negotiation facility then I think the server MUST support SPNEGO, else the client and server have to agree a priori on what mechs to use. Nico --=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 19:10:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIei-00069K-8K; Wed, 18 Jul 2007 19:10:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIeg-00066Z-HS for tls@ietf.org; Wed, 18 Jul 2007 19:10:02 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBIef-0000sY-5F for tls@ietf.org; Wed, 18 Jul 2007 19:10:02 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6IN9x9k022292 for ; Wed, 18 Jul 2007 23:10:00 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6IN9x5a002260 for ; Wed, 18 Jul 2007 17:09:59 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6IN9xMT025111 for ; Wed, 18 Jul 2007 18:09:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6IN9xkc025110 for tls@ietf.org; Wed, 18 Jul 2007 18:09:59 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 18 Jul 2007 18:09:59 -0500 From: Nicolas Williams To: tls@ietf.org Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi Message-ID: <20070718230958.GS24645@Sun.COM> References: <20070718225633.GR24645@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070718225633.GR24645@Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I just noticed Martin's objection that mechanism negotiation must be done at the TLS level to avoid a failure mode where GSS is selected but no common mechanism is found, yet non-GSS/PSK TLS would have worked. The current version of the I-D allows TLS to continue to make progress if the GSS security context establishment fails. This is good, but if negotiation could be done at the TLS level then we can optimize round-trips in this corner case. I'm not sure if we care. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 19:13:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIhc-0001T6-Gf; Wed, 18 Jul 2007 19:13:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIhW-0001Ns-C1 for tls@ietf.org; Wed, 18 Jul 2007 19:12:58 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBIhV-0002c3-Fw for tls@ietf.org; Wed, 18 Jul 2007 19:12:58 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id BAA14146; Thu, 19 Jul 2007 01:12:54 +0200 (MESZ) From: Martin Rex Message-Id: <200707182312.l6INCshD026379@fs4113.wdf.sap.corp> Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 19 Jul 2007 01:12:54 +0200 (MEST) In-Reply-To: <20070718225633.GR24645@Sun.COM> from "Nicolas Williams" at Jul 18, 7 05:56:34 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Nicolas Williams wrote: > > If this protocol will not provide a way for the server to tell the > client what GSS-API mechanisms it supports or any other GSS-API > mechanism negotiation facility then I think the server MUST support > SPNEGO, else the client and server have to agree a priori on what mechs > to use. This observation is correct. But I would very much dislike calls into SPNEGO by TLS (because you really DO NOT want to layer it below TLS, where none of the fancy GSS-API extensions is accessible that everyone is inventing), unless you pave wide information highways through your TLS stack or alternative break the abstraction, extort GSSAPI object handles and function pointers held and managed by TLS to frob the GSSAPI and SPNEGO implementations directly from above TLS (bypassing TLS). This is why I want the negotiation of a common mechanism (OID) be part of the Hello extension. Its more of a selection according to the preferences of the server. It needs to be provided as a simple OID list to the TLS stack on both sides, and that could even be done in a generic fashion (not limited to a particular TLS extension). I just sent Larry a kind-of brain dump: The whole idea and concept that I envison is still under construction in my mind, but I do have a quite good feeling about it. There are a lot of things/issues to address, not only wire formats for new/additional messages, but also new semantics and new requirements for the SSL/TLS module APIs to control the new semantics. Inserting a new code layer "TLSplus" that looks like a TLS implementation (with additional features) to the application and does all the new magic is inevitable, I believe. For such an additional TLSplus code layer, we ought to define several (abstract) characteritics and semantics and provide rough guidelines how implementors might add value, bells and whistles, depending on what (primarily the server application) wants or needs. Off the top of my mind here is a crude list of characteristics that I consider important, and I believe that some of these can not be met with the current proposal: - will work with pretty much every existing and conceivable GSS-API mechanism (even v1), requiring no changes to the mechanism - minimal and generic extension(s) to TLS (not tied to any GSS-API mechanism, and maybe not limited to the gssapi-over-tls extension) - Hello extension with ability to enable the server to select a common (gssapi) mechanism (OID), ignoring of the extension and regular SSL-Handshake if no common mechanism is found - include support for server name extension (virtual hosting) which also means server-side mechanism preference lists that can be limited to a particular virtual host and provide a hint for the server for selection of a suitable gssapi acceptor credential (above TLS) - a new ContentType at the TLS record layer to reliably distinguish (and prevent confusion) of GSS-API token exchanges (following a successfully completed SSL handshake) from application data. A minimal framing protocol for the GSS-API token exchange to convey token length in order to support GSS-API context level tokens >16KByte, and maybe token type (in order to allow of a textual error message to the client over the established protected TLS channel when the acceptor side encounters and error when trying to establish the security context (this is not part of GSS-API but of the gssapi-over-tls extension). - semantics/constraints of the server certificate path validation for the client if the the gssapi-over-tls authentication extension is requested and a common gssapi mechanism is found and asserted by the server in the server hello message. - probably a possibility to ask the TLS (server) implementation to store a (size-limited) flat-memory-object of TLSplus state along with a cached TLS session that is available on SSL/TLS session resumption and flushed when TLS flushes the session cache entry. Depending on the application's desires and requirements, the TLSplus layer may want to (or need to) persist some GSS-API specific information so that this information can also be provided to the calling application on SSL/TLS session resumption. For the underlying TLS implementation, this ought to be transformed into an opaque flat-memory-object that can be free() whenever the associated SSL session cache element is flushed from the cache. - will allow the application to access arbitrary GSS-API attributes and extensions with no changes to the TLS implementation and no violation of layering principles (like using meta-knowlege to frob software-layer below TLS directly) and not having to expose internal object handles created and managed by TLS. - no changes necessary to the gssapi-over-tls spec and neither the TLS implementation if additional or new features of a gssapi mechanism become available and used by the application caller (only changes to TLSplus, and for new GSS-API features to the gssapi implementation itself). - no changes necessary to the gssapi-over-tls spec the GSS-API mechanism, TLSplus or the application when new features are added to the underlying TLS implementation - orthogonality to TLS, i.e. benefit as much as possible from improvements to TLS, like new or stronger ciphersuites, new PRF or new TLS version, without changes to TLSplus, GSS-API, app and gssapi-over-tls spec -- which pretty much precludes to hardware/require any particular ciphersuites in gssapi-over-tls itself. - protection of the client identity from network-level sniffing (something which not currently available for the SSL client certificate). Since I've been implementing a SAP-internal small "abstraction layer" on top of SSL and providing support for this and the accompanying OEM SSL library that we ship over the last 6 years, and for gssapi based single sign-on over the last 10 years, my thoughts are very close to real code that could&would implement all the necessary stuff. I firmly believe that any solution should allow both, the TLS protocol&extensions and the GSS-API protocol&extensions to evolve independently and provide new features with close to no mutual interference between GSS-API, TLS and the gssapi-over-tls spec. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 20:35:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBJzf-0000Fq-I9; Wed, 18 Jul 2007 20:35:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBJze-0000Fl-UL for tls@ietf.org; Wed, 18 Jul 2007 20:35:46 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBJzd-0004FQ-JG for tls@ietf.org; Wed, 18 Jul 2007 20:35:46 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id CAA16102; Thu, 19 Jul 2007 02:35:42 +0200 (MESZ) From: Martin Rex Message-Id: <200707190035.l6J0ZgoV001472@fs4113.wdf.sap.corp> Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 19 Jul 2007 02:35:42 +0200 (MEST) In-Reply-To: <20070718225633.GR24645@Sun.COM> from "Nicolas Williams" at Jul 18, 7 05:56:34 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Nicolas Williams wrote: > > If this protocol will not provide a way for the server to tell the > client what GSS-API mechanisms it supports or any other GSS-API > mechanism negotiation facility then I think the server MUST support > SPNEGO, else the client and server have to agree a priori on what mechs > to use. While thinking a little longer about SPNEGO a number of problems come to mind. A common mechanism OID between initiator and acceptor only means that they will be able to parse each other GSS-API tokens, it does by no way mean that authentication will work. How common is it that companies (ultimately two rival companies) have mutual trust configured between their company-internal Kerberos realms and maintain each others Kerberos principals names on their ACLs? Think about login to a public internet-accessible Web-Server for customers, partners, friends, interested parties and even rivals with product information and discussion forums. We DO use our PKI-based company-internal Single Sign-On infrastructure to login to our public Web-Servers, and we do issue SSL client certs to customers and partners for login as well. password-based logon is possible as well. If we didn't have PKI-based Single Sign-On, but instead kerberos or gssapi-based logon and also our partners had that, and both of us had gssapi-over-tls authentication enable in our browsers, then we would have the situation that SSO works for us and constantly fails if only the "common mechanism" selection of SPNEGO would be available. Trying to "poll" for suitable gssapi mechanism by calling gss_init_sec_context() for every gssapi mechanism feeding the intended www@target.f.q.d.n when compiling the mechanism OID list for SPNEGO is not a good idea. There are gssapi mechanisms that interactively prompt for a password for each and every credential access (incurred by gss_init_sec_context()) and which check/verify the target name only on receipt of the second token, which could result in 40 password-popups for a single Web-Page with 39 embedded frames,gifs,css and js... When supporting virtual hosts in a fashion as I have depicted in a previous message, then this issue could be easily solved by configuration. Assign a seperate hostname for company-internal usage that will be sent by the client browser with gssapi-over-tls extension and configure it with a virtual-host specific mechanism list for the hello-extension negotiation. Do not list Kerberos on the "externally facing" virtual host -- problem solved. Another potentially beneficial feature for developers: I can set up a single Web-Server, configure it with several different virtual hosts and individual mechanism lists, so that I can perform interoperability tests between browser and server for all gssapi mechanism just by suppling a particular URL, without having to reconfigure and restart client or server. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 20:42:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBK6C-0005lK-6C; Wed, 18 Jul 2007 20:42:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBK6A-0005lF-Pb for tls@ietf.org; Wed, 18 Jul 2007 20:42:30 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBK69-0004Nj-FH for tls@ietf.org; Wed, 18 Jul 2007 20:42:30 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Wed, 18 Jul 2007 17:42:28 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.726.0; Wed, 18 Jul 2007 17:42:28 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jul 2007 17:42:28 -0700 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 Subject: RE: [TLS] Negotiation in draft-santesson-tls-gssapi Date: Wed, 18 Jul 2007 17:41:49 -0700 Message-ID: In-Reply-To: <200707182312.l6INCshD026379@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Negotiation in draft-santesson-tls-gssapi Thread-Index: AcfJkTXC36T+UTERQ9CCKSUrENlIvAAC83qQ References: <20070718225633.GR24645@Sun.COM> from "Nicolas Williams" at Jul18, 7 05:56:34 pm <200707182312.l6INCshD026379@fs4113.wdf.sap.corp> From: Larry Zhu To: , Nicolas Williams X-OriginalArrivalTime: 19 Jul 2007 00:42:28.0328 (UTC) FILETIME=[AED03E80:01C7C99D] X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org The current ID gives us the means to do both, the GSS data can be in clear text or encrypted. The GSS-API token can contain the real GSS mechanism tokens protected by certificate-based TLS. Comparing Martin's rough proposal, the current ID optimizes for the minimal # of roundtrips and gives us more a more generic and more extensible solution.=20 The # of roundtrip is important for some applications and environments. Therefore the current ID wins with a clear cut in term of the required # of round-trips. --larry -----Original Message----- From: Martin Rex [mailto:Martin.Rex@sap.com]=20 Sent: Wednesday, July 18, 2007 4:13 PM To: Nicolas Williams Cc: tls@ietf.org Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi Nicolas Williams wrote: >=20 > If this protocol will not provide a way for the server to tell the > client what GSS-API mechanisms it supports or any other GSS-API > mechanism negotiation facility then I think the server MUST support > SPNEGO, else the client and server have to agree a priori on what mechs > to use. This observation is correct. But I would very much dislike calls into SPNEGO by TLS (because you really DO NOT want to layer it below TLS, where none of the fancy GSS-API extensions is accessible that everyone is inventing), unless you pave wide information highways through your TLS stack or alternative break the abstraction, extort GSSAPI object handles and function pointers held and managed by TLS to frob the GSSAPI and SPNEGO implementations directly from above TLS (bypassing TLS). This is why I want the negotiation of a common mechanism (OID) be part of the Hello extension. Its more of a selection according to the preferences of the server. It needs to be provided as a simple OID list to the TLS stack on both sides, and that could even be done in a generic fashion (not limited to a particular TLS extension). I just sent Larry a kind-of brain dump: The whole idea and concept that I envison is still under construction in my mind, but I do have a quite good feeling about it. There are a lot of things/issues to address, not only wire formats for new/additional messages, but also new semantics and new requirements for the SSL/TLS module APIs to control the new semantics. Inserting a new code layer "TLSplus" that looks like a TLS implementation (with additional features) to the application and does all the new magic is inevitable, I believe. For such an additional TLSplus code layer, we ought to define several (abstract) characteritics and semantics and provide rough guidelines how implementors might add value, bells and whistles, depending on what (primarily the server application) wants or needs. Off the top of my mind here is a crude list of characteristics that I consider important, and I believe that some of these can not be met with the current proposal: - will work with pretty much every existing and conceivable GSS-API mechanism (even v1), requiring no changes to the mechanism - minimal and generic extension(s) to TLS (not tied to any GSS-API mechanism, and maybe not limited to the gssapi-over-tls extension) - Hello extension with ability to enable the server to select a common (gssapi) mechanism (OID), ignoring of the extension and regular SSL-Handshake if no common mechanism is found - include support for server name extension (virtual hosting) which also means server-side mechanism preference lists that can be limited to a particular virtual host and provide a hint for the server for selection of a suitable gssapi acceptor credential (above TLS) - a new ContentType at the TLS record layer to reliably distinguish (and prevent confusion) of GSS-API token exchanges (following a successfully completed SSL handshake) from application data. A minimal framing protocol for the GSS-API token exchange to convey token length in order to support GSS-API context level tokens >16KByte, and maybe token type (in order to allow of a textual error message to the client over the established protected TLS channel when the acceptor side encounters and error when trying to establish the security context (this is not part of GSS-API but of the gssapi-over-tls extension). - semantics/constraints of the server certificate path validation for the client if the the gssapi-over-tls authentication extension is requested and a common gssapi mechanism is found and asserted by the server in the server hello message.=20 - probably a possibility to ask the TLS (server) implementation to store a (size-limited) flat-memory-object of TLSplus state along with a cached TLS session that is available on SSL/TLS session resumption and flushed when TLS flushes the session cache entry. Depending on the application's desires and requirements, the TLSplus layer may want to (or need to) persist some GSS-API specific information so that this information can also be provided to the calling application on SSL/TLS session resumption. For the underlying TLS implementation, this ought to be transformed into an opaque flat-memory-object that can be free() whenever the associated SSL session cache element is flushed from the cache. - will allow the application to access arbitrary GSS-API attributes and extensions with no changes to the TLS implementation and no violation of layering principles (like using meta-knowlege to frob software-layer below TLS directly) and not having to expose internal object handles created and managed by TLS. - no changes necessary to the gssapi-over-tls spec and neither the TLS implementation if additional or new features of a gssapi mechanism become available and used by the application caller (only changes to TLSplus, and for new GSS-API features to the gssapi implementation itself). - no changes necessary to the gssapi-over-tls spec the GSS-API mechanism, TLSplus or the application when new features are added to the underlying TLS implementation - orthogonality to TLS, i.e. benefit as much as possible from improvements to TLS, like new or stronger ciphersuites, new PRF or new TLS version, without changes to TLSplus, GSS-API, app and gssapi-over-tls spec -- which pretty much precludes to hardware/require any particular ciphersuites in gssapi-over-tls itself. - protection of the client identity from network-level sniffing (something which not currently available for the SSL client certificate). Since I've been implementing a SAP-internal small "abstraction layer" on top of SSL and providing support for this and the accompanying OEM SSL library that we ship over the last 6 years, and for gssapi based single sign-on over the last 10 years, my thoughts are very close to real code that could&would implement all the necessary stuff. I firmly believe that any solution should allow both, the TLS protocol&extensions and the GSS-API protocol&extensions to evolve independently and provide new features with close to no mutual interference between GSS-API, TLS and the gssapi-over-tls spec. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 22:05:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBLOO-0006IR-Vm; Wed, 18 Jul 2007 22:05:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBLOO-0006GU-GO for tls@ietf.org; Wed, 18 Jul 2007 22:05:24 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBLOO-0006cn-1U for tls@ietf.org; Wed, 18 Jul 2007 22:05:24 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id EAA09264; Thu, 19 Jul 2007 04:05:18 +0200 (MESZ) From: Martin Rex Message-Id: <200707190205.l6J25Dln007329@fs4113.wdf.sap.corp> Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi To: lzhu@windows.microsoft.com (Larry Zhu) Date: Thu, 19 Jul 2007 04:05:13 +0200 (MEST) In-Reply-To: from "Larry Zhu" at Jul 18, 7 05:41:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Nicolas.Williams@sun.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Larry Zhu wrote: > > The current ID gives us the means to do both, the GSS data can be in > clear text or encrypted. *I* certainly can not see that in the current draft. > > The GSS-API token can contain the real GSS > mechanism tokens protected by certificate-based TLS. How? You mean by renegotiation -- similar to how one can protect the SSL client cert? that would add roundtrips, wouldn't it? > > Comparing Martin's rough proposal, the current ID optimizes for the > minimal # of roundtrips and gives us more a more generic and more > extensible solution. If you coalesce the first GSS-API context establishment roundtrip onto the TLS finished messages you have the same amount of roundtrips for a TLS+rfc-1964 kerberos authentication than for a plain TLS handshake. Did I miss a clever roundtrip reduction of the TLS handshake in the current ID, or could there be an error in your counting? > > The # of roundtrip is important for some applications and environments. > Therefore the current ID wins with a clear cut in term of the required # > of round-trips. When SPNEGO is used in the current proposal and the optimistic token is wrong on the, then the current ID incurs an additional roundtrip. My proposal didn't need an optimistic token and therefore can not suffer such an additional-roundtrip penalty. To me, this looks like equal roundtrips, and a loss for the current ID if the optimistic token is wrong compared to my envisoned architecture. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 18 23:20:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMYV-0002nJ-Ga; Wed, 18 Jul 2007 23:19:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMYT-0002nC-My for tls@ietf.org; Wed, 18 Jul 2007 23:19:53 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBMYS-00008h-Ud for tls@ietf.org; Wed, 18 Jul 2007 23:19:53 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Wed, 18 Jul 2007 20:19:52 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.726.0; Wed, 18 Jul 2007 20:19:51 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jul 2007 20:19:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [TLS] Negotiation in draft-santesson-tls-gssapi Date: Wed, 18 Jul 2007 20:18:55 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Negotiation in draft-santesson-tls-gssapi Thread-Index: AcfJqUoQFzU3pQTSSPykMsAXzkQ7ZgACWBbo References: <200707190205.l6J25Dln007329@fs4113.wdf.sap.corp> From: Larry Zhu To: X-OriginalArrivalTime: 19 Jul 2007 03:19:51.0845 (UTC) FILETIME=[AB969550:01C7C9B3] X-Spam-Score: -106.2 (---------------------------------------------------) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Nicolas.Williams@sun.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============1472129847==" Errors-To: tls-bounces@lists.ietf.org --===============1472129847== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C9B3.8A4A6ED8" ------_=_NextPart_001_01C7C9B3.8A4A6ED8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Larry Zhu Wrote: > The GSS-API token can contain the real GSS > mechanism tokens protected by certificate-based TLS. > How? You mean by renegotiation -- similar to how one can > protect the SSL client cert? that would add roundtrips, wouldn't it? =20 you can do this in the most straightforward way, when the TLS = protection for the GSS data is in place, it should be no worse than what = is in your proposal. The difference is that this draft leaves the = options open by not requiring a TLS handshake up front. =20 An appendix can be added to illustrate how this can be done. =20 ________________________________ From: Martin Rex [mailto:Martin.Rex@sap.com] Sent: Wed 7/18/2007 7:05 PM To: Larry Zhu Cc: martin.rex@sap.com; Nicolas.Williams@sun.com; tls@ietf.org Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi Larry Zhu wrote: > > The current ID gives us the means to do both, the GSS data can be in > clear text or encrypted. *I* certainly can not see that in the current draft. > > The GSS-API token can contain the real GSS > mechanism tokens protected by certificate-based TLS. How? You mean by renegotiation -- similar to how one can protect the SSL client cert? that would add roundtrips, wouldn't it? > > Comparing Martin's rough proposal, the current ID optimizes for the > minimal # of roundtrips and gives us more a more generic and more > extensible solution. If you coalesce the first GSS-API context establishment roundtrip onto the TLS finished messages you have the same amount of roundtrips for a TLS+rfc-1964 kerberos authentication than for a plain TLS handshake. =20 Did I miss a clever roundtrip reduction of the TLS handshake in the current ID, or could there be an error in your counting? > > The # of roundtrip is important for some applications and = environments. > Therefore the current ID wins with a clear cut in term of the required = # > of round-trips. When SPNEGO is used in the current proposal and the optimistic token is wrong on the, then the current ID incurs an additional = roundtrip. My proposal didn't need an optimistic token and therefore can not suffer such an additional-roundtrip penalty. To me, this looks like equal roundtrips, and a loss for the current ID if the optimistic token is wrong compared to my envisoned architecture. -Martin ------_=_NextPart_001_01C7C9B3.8A4A6ED8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TLS] Negotiation in = draft-santesson-tls-gssapi=0A= =0A= =0A= =0A=
=0A=
=0A=

Martin Rex wrote:

=0A=

> Larry Zhu Wrote:
> The GSS-API token can contain the = real GSS
> mechanism tokens protected by certificate-based = TLS.

> How?  You mean by renegotiation -- similar to how = one can
> protect the SSL client cert?  that would add = roundtrips, wouldn't it?

=0A=

 

=0A=

you can = do this in the most straightforward way,  when the TLS = protection for the GSS data is in place, it should be no worse than what = is in your proposal. The difference is that this draft leaves the = options open by not requiring a TLS handshake up front.

=0A=

 

=0A=

 An = appendix can be added to illustrate how this can be = done.

=0A=

 
=0A=
=0A=
=0A=
=0A=
From: Martin Rex = [mailto:Martin.Rex@sap.com]
Sent: Wed 7/18/2007 7:05 = PM
To: Larry Zhu
Cc: martin.rex@sap.com; = Nicolas.Williams@sun.com; tls@ietf.org
Subject: Re: [TLS] = Negotiation in draft-santesson-tls-gssapi

=0A=
=0A=

Larry Zhu wrote:
>
> The current ID gives = us the means to do both, the GSS data can be in
> clear text or = encrypted.

*I* certainly can not see that in the current = draft.

>
> The GSS-API token can contain the real = GSS
> mechanism tokens protected by certificate-based = TLS.

How?  You mean by renegotiation -- similar to how one = can
protect the SSL client cert?  that would add roundtrips, = wouldn't it?

>
> Comparing Martin's rough proposal, the = current ID optimizes for the
> minimal # of roundtrips and gives = us more a more generic and more
> extensible solution.

If = you coalesce the first GSS-API context establishment roundtrip
onto = the TLS finished messages you have the same amount of roundtrips
for = a TLS+rfc-1964 kerberos authentication than for a plain = TLS
handshake.  

Did I miss a clever roundtrip = reduction of the TLS handshake
in the current ID, or could there be = an error in your counting?


>
> The # of roundtrip is = important for some applications and environments.
> Therefore the = current ID wins with a clear cut in term of the required #
> of = round-trips.

When SPNEGO is used in the current proposal and the = optimistic
token is wrong on the, then the current ID incurs an = additional roundtrip.
My proposal didn't need an optimistic token and = therefore can not
suffer such an additional-roundtrip = penalty.

To me, this looks like equal roundtrips, and a loss for = the current ID
if the optimistic token is wrong compared to my = envisoned = architecture.

-Martin

------_=_NextPart_001_01C7C9B3.8A4A6ED8-- --===============1472129847== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1472129847==-- From tls-bounces@lists.ietf.org Wed Jul 18 23:49:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBN1Q-0006NS-CH; Wed, 18 Jul 2007 23:49:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBN1P-0006NN-0q for tls@ietf.org; Wed, 18 Jul 2007 23:49:47 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBN1O-0002eZ-Cs for tls@ietf.org; Wed, 18 Jul 2007 23:49:46 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id FAA17018; Thu, 19 Jul 2007 05:49:41 +0200 (MESZ) From: Martin Rex Message-Id: <200707190349.l6J3nf2v013677@fs4113.wdf.sap.corp> Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi To: martin.rex@sap.com Date: Thu, 19 Jul 2007 05:49:41 +0200 (MEST) In-Reply-To: <200707190205.l6J25Dln007329@fs4113.wdf.sap.corp> from "Martin Rex" at Jul 19, 7 04:05:13 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tls@ietf.org, Nicolas.Williams@sun.com X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > > > Comparing Martin's rough proposal, the current ID optimizes for the > > minimal # of roundtrips and gives us more a more generic and more > > extensible solution. > > If you coalesce the first GSS-API context establishment roundtrip > onto the TLS finished messages you have the same amount of roundtrips > for a TLS+rfc-1964 kerberos authentication than for a plain TLS > handshake. > > Did I miss a clever roundtrip reduction of the TLS handshake > in the current ID, or could there be an error in your counting? Rechecking the spec and OpenSSL, I realize that, although such an optimization should be technically possible, it would somewhat bent the TLS existing handshake and require quite non-trivial changes to the TLS state machine and semantics of SSL_connect when trying to implement the gssapi-over-tls authentication with inital context token coalesced to the TLS finished messages in an entirely seperate code layer "TLSplus" above TLS. I notice, however, that I still consider the necessary contortions to run the entire GSS-API context establishment within TLS and the TLS handshake according to the current ID _MAGNITUDES_ worse if one also wants to make use of all the various GSS-API features and extensions. For cached&resumed SSL sessions, there are no additonal roundtrips in either case (just the unexplained dirty hacks for the current ID in order to get access to GSS-API attributes of the original full SSL handshake). Personally, I do not consider the additional roundtrips of the GSS-API context establishment a showstopper. The overhead of rfc4559 Negotiate is worse (in particular with IIS6 as a backend!), and still it is surprisingly usable--well, at least with a sane backend that issues a secure session id upon inital rfc4559 authentication and does not constantly throw 401 Unauthorized for each and every request on an established TLS-protected communication channel. That IIS6 curiosity reliably prevents pipelining of requests. Because of this, I can easily understand that Microsoft has a significant performance issue with their deployed software using rfc4559. But frankly, I strongly doubt that one additional roundtrip on a full SSL handshake is going to be performance killer. As I mentioned before, when I was involved in Analyis of Performance issues with HTTPS-protected communication in High-end installations of our software, the only time when the SSL handshake became an issue was when the server SSL session cache size was too small leading to a 50:1 ratio in full handshakes vs. session resumes compared to a 1:30 ration in full handshakes vs. session resumes on new network connetions with a sufficiently large session cache size. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 19 08:23:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBV2d-0004hb-I8; Thu, 19 Jul 2007 08:23:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBV2c-0004hO-5o for tls@ietf.org; Thu, 19 Jul 2007 08:23:34 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBV2a-0004Pr-Nk for tls@ietf.org; Thu, 19 Jul 2007 08:23:34 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6JCNCnG024056; Thu, 19 Jul 2007 15:23:21 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 15:22:57 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 15:22:56 +0300 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 Subject: RE: [TLS] Signature Hash Agility Date: Thu, 19 Jul 2007 15:22:56 +0300 Message-ID: In-Reply-To: <20070629160611.750F933C1A@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Signature Hash Agility Thread-Index: Ace6Z7n/CU7Lvw/ORgu4GYVJENqifgPlaW1w References: <20070629160611.750F933C1A@delta.rtfm.com> From: To: , X-OriginalArrivalTime: 19 Jul 2007 12:22:56.0924 (UTC) FILETIME=[89CF0DC0:01C7C9FF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > 3. Communicating the signature/hash algorithm you're using So, I > agree that trying to figure out the hash from the signature > algorithm in the cert was a mistake. We clearly need to explicitly > name the digest algorithm in the message. However, previewing point > (4), DSA keys need to be bound to one specific digest algorithm. > Accordingly I think the right structure is: >=20 > struct { > select (SignatureAlgorithm) { > case anonymous: struct { }; > case rsa: > HashType digestAlgorithm; // NEW > digitally-signed struct { > opaque hash[Hash.length]; > }; > case dsa: > digitally-signed struct { > opaque sha_hash[20]; > }; > }; > }; > } Signature; >=20 >=20 > And note that we'll need DigestInfo encoding to protect against hash > substitution. I'd prefer a more uniform approach: struct { opaque signature_algorithm<0..2^16-1>; opaque signature_value<0..2^16-1>; } Signature; where signature_algorithm is DER-encoded AlgorithmIdentifier structure, and signature_value is the actual signature value=20 (and for anonymous, both are just zero-length strings). This would work even in the case of ANSI X9.62 encoded ECDSA=20 public keys, where SPKI can list more than one acceptable hash=20 algorithm. (If they're all secure, substitution may not be=20 a problem; IMHO this is a CA policy issue, and we shouldn't hardcode this in TLS.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 19 19:16:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfEj-00049z-V5; Thu, 19 Jul 2007 19:16:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfEh-00049o-Tn for tls@ietf.org; Thu, 19 Jul 2007 19:16:43 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBfEh-0007xQ-Bg for tls@ietf.org; Thu, 19 Jul 2007 19:16:43 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6JNGgH9002429 for ; Thu, 19 Jul 2007 23:16:42 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6JNGf3H003867 for ; Thu, 19 Jul 2007 17:16:41 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6JNGf99026078; Thu, 19 Jul 2007 18:16:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6JNGee6026077; Thu, 19 Jul 2007 18:16:40 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 19 Jul 2007 18:16:40 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi Message-ID: <20070719231639.GZ25464@Sun.COM> References: <200707190205.l6J25Dln007329@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707190205.l6J25Dln007329@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Thu, Jul 19, 2007 at 04:05:13AM +0200, Martin Rex wrote: > Larry Zhu wrote: > > > > The current ID gives us the means to do both, the GSS data can be in > > clear text or encrypted. > > *I* certainly can not see that in the current draft. > > > > > The GSS-API token can contain the real GSS > > mechanism tokens protected by certificate-based TLS. > > How? You mean by renegotiation -- similar to how one can > protect the SSL client cert? that would add roundtrips, wouldn't it? By nesting TLS. > > Comparing Martin's rough proposal, the current ID optimizes for the > > minimal # of roundtrips and gives us more a more generic and more > > extensible solution. > > If you coalesce the first GSS-API context establishment roundtrip > onto the TLS finished messages you have the same amount of roundtrips > for a TLS+rfc-1964 kerberos authentication than for a plain TLS > handshake. The way TLS works it depends on the finished message derivation having as input all preceding hello and handshake messages, and in order. This means that at most one GSS-API token can be sent in the same "write" as a Finished message. There is no way to piggyback a 1 round-trip GSS context token exchange onto the full handshake pictured in figure 1 of RFC4346. Nor is there a way to piggiback the first context token into the client Hello message without first extending the client Hello, but how can we extend the client Hello? (AFAICS we cannot.) > Did I miss a clever roundtrip reduction of the TLS handshake > in the current ID, or could there be an error in your counting? I think Larry meant that if the GSS-API context fails to be established then we can fallback on other TLS key exchange and/or authentication methods, which means that in some cases the use of the GSS-API will only add round-trips. One reason the GSS-API security context establishment might fail is that the client tried a mechanism not supported by the server. This is preventable, either by using SPNEGO or by extending the server Hello to allow the server to advertise what mechanisms it supports and has acceptor credentials for. That is, by providing for negotiation of GSS mechanisms, one way or another, we can eliminate a situation in which this extension might do nothing more than add a round-trip. BTW, the protocol in figure 1 of draft-santesson-tls-gssapi is confusing: the server can't be the first to send a TokenTransfer unless it sends an empty one (because the GSS-API is an initiator-sends-first framework). Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 19 19:19:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfHc-0005ew-Uk; Thu, 19 Jul 2007 19:19:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfHb-0005eh-TB for tls@ietf.org; Thu, 19 Jul 2007 19:19:43 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBfHb-00082M-7z for tls@ietf.org; Thu, 19 Jul 2007 19:19:43 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6JNJgYY003228 for ; Thu, 19 Jul 2007 23:19:42 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6JNJguA005072 for ; Thu, 19 Jul 2007 17:19:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6JNJgAN026092; Thu, 19 Jul 2007 18:19:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6JNJg7Q026091; Thu, 19 Jul 2007 18:19:42 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 19 Jul 2007 18:19:42 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi Message-ID: <20070719231941.GA25464@Sun.COM> References: <200707190205.l6J25Dln007329@fs4113.wdf.sap.corp> <200707190349.l6J3nf2v013677@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707190349.l6J3nf2v013677@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Thu, Jul 19, 2007 at 05:49:41AM +0200, Martin Rex wrote: > I notice, however, that I still consider the necessary contortions > to run the entire GSS-API context establishment within TLS and > the TLS handshake according to the current ID _MAGNITUDES_ worse > if one also wants to make use of all the various GSS-API > features and extensions. One should not. This I-D is roughly akin to RFC4462 (SSHv2 w/ GSS). > For cached&resumed SSL sessions, there are no additonal roundtrips > in either case (just the unexplained dirty hacks for the current ID > in order to get access to GSS-API attributes of the original > full SSL handshake). Correct. > Personally, I do not consider the additional roundtrips of the > GSS-API context establishment a showstopper. The overhead of Me either. But that's not what Larry meant, I think. See my other reply just now. Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 19 19:19:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfHf-0005kc-96; Thu, 19 Jul 2007 19:19:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfHc-0005em-6S for tls@ietf.org; Thu, 19 Jul 2007 19:19:44 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBfHb-0005P6-HP for tls@ietf.org; Thu, 19 Jul 2007 19:19:44 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 19 Jul 2007 16:19:42 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.726.0; Thu, 19 Jul 2007 16:19:42 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Jul 2007 16:19:42 -0700 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 Subject: RE: [TLS] Negotiation in draft-santesson-tls-gssapi Date: Thu, 19 Jul 2007 16:19:16 -0700 Message-ID: In-Reply-To: <20070719231639.GZ25464@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Negotiation in draft-santesson-tls-gssapi Thread-Index: AcfKWua5lmQYgUV/R7uVkE/BhZYhzwAACiGQ References: <200707190205.l6J25Dln007329@fs4113.wdf.sap.corp> <20070719231639.GZ25464@Sun.COM> From: Larry Zhu To: Nicolas Williams , Martin Rex X-OriginalArrivalTime: 19 Jul 2007 23:19:42.0069 (UTC) FILETIME=[491B0250:01C7CA5B] X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Nicolas Williams wrote: > BTW, the protocol in figure 1 of draft-santesson-tls-gssapi is > confusing: the server can't be the first to send a TokenTransfer unless it sends an empty one (because the GSS-API is an initiator-sends-first=20 > framework). This is a typographical error that has been fixed in -03 at http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx t. -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Thursday, July 19, 2007 4:17 PM To: Martin Rex Cc: Larry Zhu; tls@ietf.org Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi On Thu, Jul 19, 2007 at 04:05:13AM +0200, Martin Rex wrote: > Larry Zhu wrote: > >=20 > > The current ID gives us the means to do both, the GSS data can be in > > clear text or encrypted. >=20 > *I* certainly can not see that in the current draft. >=20 > > > > The GSS-API token can contain the real GSS > > mechanism tokens protected by certificate-based TLS. >=20 > How? You mean by renegotiation -- similar to how one can > protect the SSL client cert? that would add roundtrips, wouldn't it? By nesting TLS. > > Comparing Martin's rough proposal, the current ID optimizes for the > > minimal # of roundtrips and gives us more a more generic and more > > extensible solution.=20 >=20 > If you coalesce the first GSS-API context establishment roundtrip > onto the TLS finished messages you have the same amount of roundtrips > for a TLS+rfc-1964 kerberos authentication than for a plain TLS > handshake. =20 The way TLS works it depends on the finished message derivation having as input all preceding hello and handshake messages, and in order. This means that at most one GSS-API token can be sent in the same "write" as a Finished message. There is no way to piggyback a 1 round-trip GSS context token exchange onto the full handshake pictured in figure 1 of RFC4346. Nor is there a way to piggiback the first context token into the client Hello message without first extending the client Hello, but how can we extend the client Hello? (AFAICS we cannot.) > Did I miss a clever roundtrip reduction of the TLS handshake > in the current ID, or could there be an error in your counting? I think Larry meant that if the GSS-API context fails to be established then we can fallback on other TLS key exchange and/or authentication methods, which means that in some cases the use of the GSS-API will only add round-trips. One reason the GSS-API security context establishment might fail is that the client tried a mechanism not supported by the server. This is preventable, either by using SPNEGO or by extending the server Hello to allow the server to advertise what mechanisms it supports and has acceptor credentials for. That is, by providing for negotiation of GSS mechanisms, one way or another, we can eliminate a situation in which this extension might do nothing more than add a round-trip. BTW, the protocol in figure 1 of draft-santesson-tls-gssapi is confusing: the server can't be the first to send a TokenTransfer unless it sends an empty one (because the GSS-API is an initiator-sends-first framework). Nico --=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 19 19:28:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfQR-00052i-8Q; Thu, 19 Jul 2007 19:28:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfQP-00052Z-8B for tls@ietf.org; Thu, 19 Jul 2007 19:28:49 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBfQO-0008MK-ND for tls@ietf.org; Thu, 19 Jul 2007 19:28:49 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6JNSjbT026499 for ; Thu, 19 Jul 2007 23:28:45 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6JNSj7m008728 for ; Thu, 19 Jul 2007 17:28:45 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6JNSjib026103; Thu, 19 Jul 2007 18:28:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6JNSjDU026102; Thu, 19 Jul 2007 18:28:45 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 19 Jul 2007 18:28:45 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi Message-ID: <20070719232844.GB25464@Sun.COM> References: <20070718225633.GR24645@Sun.COM> <200707190035.l6J0ZgoV001472@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707190035.l6J0ZgoV001472@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Thu, Jul 19, 2007 at 02:35:42AM +0200, Martin Rex wrote: > While thinking a little longer about SPNEGO a number of problems > come to mind. > > A common mechanism OID between initiator and acceptor only means > that they will be able to parse each other GSS-API tokens, > it does by no way mean that authentication will work. > > How common is it that companies (ultimately two rival companies) > have mutual trust configured between their company-internal > Kerberos realms and maintain each others Kerberos principals names > on their ACLs? Funny, I sent an e-mail to Sam last night proposing that we talk tomorrow (we'll be in the same city) about the identity selection problem. I think it'd be nice to have a way to negotiate which "federation" (to borrow a suitable term from the world of Liberty and other identity schemes) to use. I picture a (forgive me) stackable pseudo-mechanism by which the client and server can agree on a federation. In general it should be sufficient, and better, for the server to tell the client what the federations are that it participates in, ASAP, so that in protocols where there's a chance to do that before the GSS context establishment starts then no round-trip penalty is incurred. However, there are issues to think about. Protecting the negotiation is an obvious one. Privacy protection of the client's identity(ies) is another. One thing that seems nice is that "federation" names can be independent of authentication mechanisms. A PKI, Kerberos and or Liberty federation would be a world of domains/realms where entities (such as users and servers) should be able to authenticate each other provided that they have valid credentials). Federated world negotiation is part of the identity selection problem. Of course, the identity selection problem is still non-trivial to solve even if we solve the federated world negotiation problem. Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 19 19:54:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfpN-0007ax-Kz; Thu, 19 Jul 2007 19:54:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfpN-0007as-7I for tls@ietf.org; Thu, 19 Jul 2007 19:54:37 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBfpM-0000ZO-Ed for tls@ietf.org; Thu, 19 Jul 2007 19:54:37 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id BAA05337; Fri, 20 Jul 2007 01:54:25 +0200 (MESZ) From: Martin Rex Message-Id: <200707192354.l6JNsPkJ029220@fs4113.wdf.sap.corp> Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 20 Jul 2007 01:54:25 +0200 (MEST) In-Reply-To: <20070719231639.GZ25464@Sun.COM> from "Nicolas Williams" at Jul 19, 7 06:16:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Martin.Rex@sap.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Nicolas Williams wrote: > > > > Comparing Martin's rough proposal, the current ID optimizes for the > > > minimal # of roundtrips and gives us more a more generic and more > > > extensible solution. > > > > If you coalesce the first GSS-API context establishment roundtrip > > onto the TLS finished messages you have the same amount of roundtrips > > for a TLS+rfc-1964 kerberos authentication than for a plain TLS > > handshake. > > The way TLS works it depends on the finished message derivation having > as input all preceding hello and handshake messages, and in order. This > means that at most one GSS-API token can be sent in the same "write" as > a Finished message. This is be a YES (to sending one context-level gss-api token). > There is no way to piggyback a 1 round-trip GSS > context token exchange onto the full handshake pictured in figure 1 of > RFC4346. This is a NO. I'm confused. What I was thinking of was piggybacking the initators first context level token onto the client's finished message and the acceptors first context level token onto the servers finished message. I admit that I'm not sufficiently familiar with the crypto of the SSL/TLS handshake to determine whether this is possible. I just noticed, that technically implementations like OpenSSL have implemented the exchange of the Finished messages in a half-duplex fashion. I don't know whether this is strict requirement from the protocol or whether it is because it is easier to implement and it wouldn't be a good idea to let the client application send data before the server's finished message was received and verified. If the latter, then there is no technical issue against sending the initiators first context level token without waiting for the servers finished message. But for architectures like OpenSSL, piggybacking on the client finished message would require a significant change of the clients state machine and SSL_connect API semantics, which is why *I* would not put such an optimization into OpenSSL... If I understand Microsoft's software architecture correctly, then they have a TLS implementation without transport, where adding such an optimization should be _much_ easier to add and be fairly compatible to the exitinge API semantics. > > Nor is there a way to piggiback the first context token into > the client Hello message without first extending the client Hello, but > how can we extend the client Hello? (AFAICS we cannot.) Hello extensions should work with SSLv3 already. Is there a size limitation on the Hello extension? (because there is no size limitation on the gssapi context level tokens). > > > Did I miss a clever roundtrip reduction of the TLS handshake > > in the current ID, or could there be an error in your counting? > > I think Larry meant that if the GSS-API context fails to be established > then we can fallback on other TLS key exchange and/or authentication > methods, which means that in some cases the use of the GSS-API will only > add round-trips. > > One reason the GSS-API security context establishment might fail is that > the client tried a mechanism not supported by the server. This is > preventable, either by using SPNEGO or by extending the server Hello to > allow the server to advertise what mechanisms it supports and has > acceptor credentials for. Coming up with good "fallback semantics" will be challenging. Fallback to the regular TLS handshake when there is no common gssapi mechanism is fine (similar to my idea). Fallback if the security context establishment fails is not necessarily a good idea, because if you really want gss-api based authentication and that fails for a technical reason, you will not see the GSS-API error, but instead get a fallback to the TLS handshake. Several serious bugs in Microsoft Kerberos go unnoticed because of the fallback to NTLM kicking in for most of Microsoft's own communication protocols. On the one hand this is a security problem (NTLM authentication is significantly weaker than Kerberos), and on the other it becomes a showstopper for (mosty non-Microsoft-only) scenarios where the use of Kerberos is a requirement. Fallback for an unsupported/unavailable feature is usualls OK, fallback for a security-relevant error is often the cause of security vulnerabilities or mysterious behaviours (works sometimes but not always). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 19 20:20:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBgEW-000376-RW; Thu, 19 Jul 2007 20:20:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBgEV-000371-F6 for tls@ietf.org; Thu, 19 Jul 2007 20:20:35 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBgEV-0006ta-0x for tls@ietf.org; Thu, 19 Jul 2007 20:20:35 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id CAA23717; Fri, 20 Jul 2007 02:20:29 +0200 (MESZ) From: Martin Rex Message-Id: <200707200020.l6K0KTdL000752@fs4113.wdf.sap.corp> Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi To: martin.rex@sap.com Date: Fri, 20 Jul 2007 02:20:29 +0200 (MEST) In-Reply-To: <200707192354.l6JNsPkJ029220@fs4113.wdf.sap.corp> from "Martin Rex" at Jul 20, 7 01:54:25 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tls@ietf.org, Nicolas.Williams@sun.com X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > > > Nor is there a way to piggiback the first context token into > > the client Hello message without first extending the client Hello, but > > how can we extend the client Hello? (AFAICS we cannot.) > > Hello extensions should work with SSLv3 already. > Is there a size limitation on the Hello extension? > (because there is no size limitation on the gssapi context level tokens). A while back we had a discussion about changing the TLS PRF. Then it was suggested that it should be OK if both parties have to keep all SSL handshake messages around in order to compute the finished messages. I don't think this would be a good idea if there is no size limit on the size of the entire SSL/TLS handshake. Do we really want to have the entire GSS-API token exchange WITHIN the TLS handshake? Even in the "good" case, this may be a significant amount of data. The initial SPNEGO token may be carrying a wrongly guessed initial context token of a gssapi mechanism not offered by the server, and then you also get the full handshake of the common mechanism. The decision of a TLS server to abort a handshake because of an excessively large Hello extension itself might be easier than to tell from which size on a huge optimistic context token for an (potentially unsupported) gssapi mechanism in the SPNEGO token should be considered an offense or attack deserving a FATAL SSL alert... -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 19 21:19:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBh9G-0001YS-O6; Thu, 19 Jul 2007 21:19:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBh9F-0001XD-EE for tls@ietf.org; Thu, 19 Jul 2007 21:19:13 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBh9D-00006w-Nx for tls@ietf.org; Thu, 19 Jul 2007 21:19:13 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id B8A67741E8; Fri, 20 Jul 2007 03:19:10 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01145-01-4; Fri, 20 Jul 2007 03:19:09 +0200 (CEST) Received: from [192.168.1.52] (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id B1C7774149; Fri, 20 Jul 2007 03:19:08 +0200 (CEST) In-Reply-To: <200707181824.l6IIOItm018779@fs4113.wdf.sap.corp> References: <200707181824.l6IIOItm018779@fs4113.wdf.sap.corp> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24B64CBC-C516-4CE1-B032-ADE2580D2BF5@it.su.se> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for Date: Thu, 19 Jul 2007 21:19:04 -0400 To: martin.rex@sap.com X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.312 tagged_above=-99 required=7 tests=[BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org 18 jul 2007 kl. 20.24 skrev Martin Rex: > =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= wrote: >> >> Comment on the draft draft-santesson-tls-gssapi-03.txt >> >> - An important goal to meet is enabling use of authentication >> infrastructure of the GSS mech for server and client >> authenticiation. When using gss server authentication, thers shold >> be no need to have a certificate on the server. > > I agree that there should NOT be a need for a fully configured PKI. > > I completely disagree on the absense of a Certificate-based server > credential. A fallback self-signed cert is a no-brainer. > > Do you seriously propose to give up on a mandatory-to-implement > authentication scheme that will provide interoperability when > your locally-preferred authentication scheme (GSS-API) is > unavailable. > > SSL started off with mandatory to implement ciphersuites in order > to provide interoperability, and historically, these used a > certificate-based credential. Yes. I think there is an requirement to not need a x509 certificate at all to run the gssapi tls functionallity. How is this conflicting with anything you write above ? >> - Feedback of key-data from the GSS-MECH back into the tls >> statemachine. GSS-API is more then a glorified OTP/password >> system, >> it provides key material that should be used, this solves problems >> like replay attacks w/o the need for a replay cache, etc. > > Do you know of a weakness in TLS that we don't, or what is your > rationale for this. As I already described, the majority of > GSS-API mechanisms doesn't have gss_prf and for an entire classes of > GSS-API mechanism it is impossible to provide keying material or > gss_prf. In order to mix GSS-API-based keying material into the > TLS key exchange you will have to MESS severely with TLS internals. > > Unless you can show that TLS key establishment is weak or broken, > such messing around with TLS internal is a pretty bad idea -- and > even if you could show -- we should rather fix TLS instead of > messing with the TLS key exchange. > > First of all, the GSS-API mechanism should protect against replay > attacks all by itself. Where that is insufficient, the additional > use of GSS-API channel bindings should do the trick. > At a first glance, the use of the SSL session ID should be sufficient. > (unless the SSL/TLS stack uses a really braindead algorithm to > generate SSL session IDs.) Replay or tunneling attacks is what I worry about. With the lack checking of binding or folding keymaterial from gss-api into tls. For example, an gssapi connection done in clear can be tunneled into a protected channel and if there is no verification that the sender/ recviers have access to the resulting context (using gss_wrap/gss_get_mic) there is no actual authenticaition going on. On real world example of this is using ssh this the gss-userauth (not gss-userauth-with-mic), then an attacker can pick up an ftp-gss connection to the same host and tunnel it into the ssh connection and get logged in. Thats why I say that gss should contribute with/authenticate the key material, either by prf or get-mic. Thats why I say that gss-api is not a OTP/password system, you can't treat as it is. >> - I would prefer having both the ability to run gssapi in clear and >> inside a DH protected tls connection. But it should run inside TLS >> and not the application layer. I.e., not http negotiate yet again. >> Saying that all gss mechs are cryptographicly weak is wrong, >> saying >> they are strong are also wrong. Should provide both, or just >> define >> cryptographicly weak gss-mechs as out of scope for this >> solution. Defining a solution that only uses the weak mech's >> functionally seems, well, weird and quite unfriendly. > > There is a substantial security benefit in being able to perform > the GSS-API authentication under TLS encryption, namely to protect > the identity of the client from network-level sniffing. We have > heard repeated request for protection of the SSL client cert, > which unfortunately travels in the cleartext portion of the > SSL handshake (probably in an attempt to simplify the SSL state > machine > to make the encrypted part of a full handshake and the encrypted part > of a session resume alike). > > > Can you provide any technical reasons why a solution should provide > for GSS-API authentication in the cleartext part of the communication? > > "I like it" and "it's easier for me to read network traces" do not > describe > convincing technical benefits. I'm fine with introducing gss+anon-dh, but then we will get multiple DH's in stack. But you might be just fine with that. gss+anon-dh will still expose the client infomation to an active attacker in the case of gss-krb5. >> - If its required to have DN for authorisation, well have the gss- >> mech >> define that then. I really don't like how everytime naming get up, >> its assumed that TLS naming today accully works, how many apps >> actually does correct authorisation with tls certificate based >> naming today, and why should they work with gss-style names ? > > Actually, TLS does NOT do naming at all. That has been explicit > in the specs from the beginning. The details of the authentication > process is outside of the scope of TLS and must be addressed by > communication protocols built on top of TLS (like HTTP over SSL/TLS). > > The document under discussion breaks with this tradition > in a pretty bad and totally unnecessary fashion. >> This proposed solutions fixes 1, 2, 3, and 4. But thats becase I >> think weak gss mechs should be thrown out the window. > > The strength of a cryptographic protocol wears off (quickly) over > time. > > This is one of the reasons why I would greatly prefer an approach > orthogonal to the TLS protocol engine. If you do the GSS-API > handshake > after the TLS handshake, under TLS protection, using the SSL Record > protocol and probably with a different "container tag" than regular > application data (so no-one will confuse it with application data), > then improvements to TLS (like new and stronger ciphersuites) > can be used as soon as they become available, entirely independent > of the inner GSS-API authentication and without having to update > the gssapi-over-tls specification. > > >> >> Saying SPKM doesn't support gss-psudeo random is just silly, >> SPKM doesn't support anything, its not implementable and >> I want better security then des/rc2. > > You seem to confuse the mandatory to implement symmetric ciphers > in rfc-2025 with the stuff that really gets used in productive > deployments. "Do you seriously propose to give up on a mandatory-to-implement authentication scheme that will provide interoperability." rfc2025 doesn't specifify how to do padding for CONF ciphers for non des/des3. INT is specififed using a stream key for des, but using rsa-sign- for all other types. You like doing one RSA operation per packet ? Everytime I look as SPKM I get sad. But this is not the right place to talk about SPKM. > About 6 different vendors have certified for interoperability > with our application with SPKM-based gssapi mechanisms and > 4 more with SPKM-like mechanisms. Doing this costs them real money, > and they wouldn't have done it when there weren't any of our customers > using these third-party products and paying for it. And yet, rfc2025 (spkm) doesn't specify a default dh group, nor a way to negotiate them. > I'm getting the impression that it might be much easier for me > to write an I-D with a well-designed proposal than to continue > bashing on draft-santesson-tls-gssapi-03.txt > > But I'm not a TLS expert (I only have been doing support and > some improvements the last 6 years for an OEM library that we ship), > and would need help/advice on how to add the extension with > the least possible impact the maximum orthogonality to the > TLS architecture (in order to continuously benefit from TLS > evolution). Clearly we are no TLS experts either. Maybe you could write a simple document that describe how you want it to work so Larry, Stefan and Jeff can see if that is acceptable for their problems and let them fill out the rest ? Love _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 19 23:44:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBjPH-0001GG-VF; Thu, 19 Jul 2007 23:43:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBjPG-0001G4-Pw for tls@lists.ietf.org; Thu, 19 Jul 2007 23:43:54 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBjPF-0003Pp-Kc for tls@lists.ietf.org; Thu, 19 Jul 2007 23:43:54 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 19 Jul 2007 20:43:52 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.726.0; Thu, 19 Jul 2007 20:43:52 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Jul 2007 20:43:51 -0700 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, 19 Jul 2007 20:43:04 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: encrypting GSS data: draft-santesson-tls-gssapi-03.txt Thread-Index: AcfKgBRSwlvoK/bCRFmnbpY64QPgww== From: Larry Zhu To: X-OriginalArrivalTime: 20 Jul 2007 03:43:51.0731 (UTC) FILETIME=[303D8030:01C7CA80] X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org A new section is inserted in -03: the TCPWrap pseudo mechanism is defined to describe how to TLS protect GSS-data. http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx t 6. Protecting GSS-API Authentication Data GSS-API [RFC2743] provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. For example, Kerberos is a GSS-API mechanism defined in [RFC4121]. It is possible to design a GSS-API mechanism that can be used with FKA-TLS in order to, for example, provide client authentication, and is so weak that its GSS- API token MUST NOT be in clear text over the open network. A good example is a GSS-API mechanism that implements basic authentication. Although such mechanisms are unlikely to be standardized and will be encouraged in no circumstance, they exist for practical reasons. In order to provide a standard way for protecting weak GSS-API data for use over FKA-TLS, TLSWrap is defined in this section as a pseudo GSS-API mechanism that wraps around the real GSS-API authentication context establishment tokens. This pseudo GSS-API mechanism does not provide per-message security. The syntax of the initial TLSWrap token follows the initialContextToken syntax defined in Section 3.1 of [RFC2743]. The TLSWrap pseudo mechanism is identified by the Object Identifier iso.org.dod.internet.security.mechanism.tls-wrap (1.3.6.1.5.5.16). Subsequent TLSWrap tokens MUST NOT be encapsulated in this GSS-API generic token framing. TLSWrap encapsulates the TLS handshake and data protection in its context establishment tokens. The innerContextToken [RFC2743] for the initial TLSWrap context token contains the ClientHello message encoded according to [RFC4346]. No PSK ciphersuite can be included in the client hello message. The targ_name is used by the client to identify the server and it follows the name forms defined in Section 4 of [PKU2U]. Upon receipt of the initial TLSWrap context token, the GSS-API server processes the client hello message. The output GSS-API context token for TLSWrap contains the ServerHello message and the ServerHelloDone potentially with the optional handshake messages in the order as defined in [RFC4346]. The GSS-API client then processes the server reply and returns the ClientKeyExchange message and the Finished message potentially with the optional handshake messages in the order as defined in [RFC4346]. The client places the real GSS-API authentication mechanism token as an application data record right after the TLS Finished message in the same GSS-API context token for TLSWrap. Because the real mechanism token is placed after the ChangeCipherSpec message, the GSS-API data for the real mechanism is encrypted. If the GSS-API server is not authenticated at this point of the TLS handshake for TLSWrap, the TLSWrap context establishment MUST fail and the real authentication mechanism token MUST not be returned. The GSS-API server in turn processes the client reply and returns the TLS Finished message, the server places the reply token from the real authentication mechanism, if present, as an application data record. If additional TLS messages are needed before the application data, these additional TLS messages are encapsulated in the context token of TLSWrap in the same manner how the client hello and server hello message are encapsulated as described above. If additional tokens are required by the real authentication mechanism in order to establish the context, these tokens are placed as an application data record, encoded according to [RFC4346] and then returned as TLSWrap GSS-API context tokens, with one TLSWrap context token per each real mechanism context token. The real mechanism context tokens are decrypted by TLSWrap and then supply to the real mechanism to complete the context establishment. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 19 23:48:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBjTE-0004Fs-1T; Thu, 19 Jul 2007 23:48:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBjTC-0004Fn-9i for tls@ietf.org; Thu, 19 Jul 2007 23:47:58 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBjTA-0003TY-WC for tls@ietf.org; Thu, 19 Jul 2007 23:47:58 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 19 Jul 2007 20:47:56 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.726.0; Thu, 19 Jul 2007 20:47:55 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Jul 2007 20:47:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {66E9B0C5-EE30-45C6-8155-764B35A7322C} MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: IO4= ACPe AX6K BUf6 BadU CETZ DR31 DbZW Ed3y EvwB E44s Fl0Z FsfG GFaX Gyg3 HiXq; 1; dABsAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {66E9B0C5-EE30-45C6-8155-764B35A7322C}; bAB6AGgAdQBAAHcAaQBuAGQAbwB3AHMALgBtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAA==; Fri, 20 Jul 2007 03:47:10 GMT; QQBwAHAAZQBuAGQAaQB4ACAAQgAuACAAIABBAGQAZABpAHQAaQBvAG4AYQBsACAAVQBzAGUAIABDAGEAcwBlAHMAIABmAG8AcgAgAEYAWABBAC0AVABMAFMAOgAgAGQAcgBhAGYAdAAtAHMAYQBuAHQAZQBzAHMAbwBuAC0AdABsAHMALQBnAHMAcwBhAHAAaQAtADAAMwAuAHQAeAB0AA== Content-Class: urn:content-classes:message Date: Thu, 19 Jul 2007 20:47:10 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Appendix B. Additional Use Cases for FXA-TLS: draft-santesson-tls-gssapi-03.txt Thread-Index: AcfKgKakP4lErjd5S/+bPtuGra64uw== From: Larry Zhu To: X-OriginalArrivalTime: 20 Jul 2007 03:47:55.0761 (UTC) FILETIME=[C1B18610:01C7CA80] X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Subject: [TLS] Appendix B. Additional Use Cases for FXA-TLS: draft-santesson-tls-gssapi-03.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Pasi requested more use cases that are not HTTP and he asked why RFC4559 is not sufficient.=20 In response, appendix B is added. Please see if this satisfies the requirements.=20 I would like thank Ryan for helping with the use cases. http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx t Appendix B. Additional Use Cases for FXA-TLS TLS runs on layers beneath a wide range of application protocols such as LDAP [RFC4510], SMTP [RFC2487], and XMPP [RFC3920] and above a reliable transport protocol. TLS can add security to any protocol that uses reliable connections (such as TCP). TLS is also increasingly being used as the standard method for protecting SIP [RFC3261] application signaling. TLS can be used to provide authentication and encryption of the SIP signaling associated with VOIP (Voice over IP) and other SIP-based applications. Today these applications use public key certificates to verify the identity of endpoints. However, how to manage the issuance level of certificates when deploying PKI is overwhelmingly complex and such complexity has gradually eroded the confidence for the PKI-based systems in general. In addition, the perceived overhead of deploying and managing certificates is high. As a consequence, the industry badly needs the ability to secure TLS connections by leveraging the existing credential infrastructure. For many customers that means Kerberos. It is highly desirable to enable PKI-less deployments yet still offer strong authentication. Having Kerberos/GSS-API in the layer above TLS means all TLS applications need to be changed in the protocol level. In many cases, such changes are not technically feasible. For example, [RFC4559] provides integration with Kerberos in the HTTP level. It suffers from a couple of drawbacks, most notably it only supports single-round-trip GSS-API mechanisms and it lacks of channel bindings to the underlying TLS connection which makes in unsuitable for deployment in situations where proxies exists. Furthermore, [RFC4559] lacks of session-based re-authentication (comparing with TLS). The root causes of these problems are inherent to the HTTP protocol and can't be fixed trivially. Consequently, It is a better solution to integrate Kerberos/GSS-API in the TLS layer. Such integration allows the existing infrastructure work seamlessly with TLS for the products based on them in ways that were not practical to do before. For instance, an increasing number of client and server products support TLS natively, but many still lack support. As an alternative, users may wish to use standalone TLS products that rely on being able to obtain a TLS connection immediately, by simply connecting to a separate port reserved for the purpose. For example, by default the TCP port for HTTPS is 443, to distinguish it from HTTP on port 80. TLS can also be used to tunnel an entire network stack to create a VPN, as is the case with OpenVPN. Many vendors now marry TLS's encryption and authentication capabilities with authorization. There has also been substantial development since the late 1990s in creating client technology outside of the browser to enable support for client/server applications. When compared against traditional IPSec VPN technologies, TLS has some inherent advantages in firewall and NAT traversal that make it easier to administer for large remote-access populations. PSK-TLS as defined in [RFC4279] is a good start but this document finishes the job by making it more deployable. FKA-TLS also fixes the mutual-authentication problem in [RFC4279] in the cases where the PSK can be shared among services on the same host. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 19 23:48:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBjUB-0004XO-If; Thu, 19 Jul 2007 23:48:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBjUA-0004XI-Jv for tls@ietf.org; Thu, 19 Jul 2007 23:48:58 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBjUA-0003UK-2F for tls@ietf.org; Thu, 19 Jul 2007 23:48:58 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 19 Jul 2007 20:48:57 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) with Microsoft SMTP Server id 8.0.726.0; Thu, 19 Jul 2007 20:48:56 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Jul 2007 20:48:56 -0700 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, 19 Jul 2007 20:48:43 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: encrypting GSS data: draft-santesson-tls-gssapi-03.txt Thread-Index: AcfKgBRSwlvoK/bCRFmnbpY64QPgwwAAL8rA From: Larry Zhu To: X-OriginalArrivalTime: 20 Jul 2007 03:48:56.0618 (UTC) FILETIME=[E5F790A0:01C7CA80] X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Subject: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org A new section is inserted in -03: the TCPWrap pseudo mechanism is defined to describe how to TLS protect GSS-data. http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx t 6. Protecting GSS-API Authentication Data GSS-API [RFC2743] provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. For example, Kerberos is a GSS-API mechanism defined in [RFC4121]. It is possible to design a GSS-API mechanism that can be used with FKA-TLS in order to, for example, provide client authentication, and is so weak that its GSS- API token MUST NOT be in clear text over the open network. A good example is a GSS-API mechanism that implements basic authentication. Although such mechanisms are unlikely to be standardized and will be encouraged in no circumstance, they exist for practical reasons. In order to provide a standard way for protecting weak GSS-API data for use over FKA-TLS, TLSWrap is defined in this section as a pseudo GSS-API mechanism that wraps around the real GSS-API authentication context establishment tokens. This pseudo GSS-API mechanism does not provide per-message security. The syntax of the initial TLSWrap token follows the initialContextToken syntax defined in Section 3.1 of [RFC2743]. The TLSWrap pseudo mechanism is identified by the Object Identifier iso.org.dod.internet.security.mechanism.tls-wrap (1.3.6.1.5.5.16). Subsequent TLSWrap tokens MUST NOT be encapsulated in this GSS-API generic token framing. TLSWrap encapsulates the TLS handshake and data protection in its context establishment tokens. The innerContextToken [RFC2743] for the initial TLSWrap context token contains the ClientHello message encoded according to [RFC4346]. No PSK ciphersuite can be included in the client hello message. The targ_name is used by the client to identify the server and it follows the name forms defined in Section 4 of [PKU2U]. Upon receipt of the initial TLSWrap context token, the GSS-API server processes the client hello message. The output GSS-API context token for TLSWrap contains the ServerHello message and the ServerHelloDone potentially with the optional handshake messages in the order as defined in [RFC4346]. The GSS-API client then processes the server reply and returns the ClientKeyExchange message and the Finished message potentially with the optional handshake messages in the order as defined in [RFC4346]. The client places the real GSS-API authentication mechanism token as an application data record right after the TLS Finished message in the same GSS-API context token for TLSWrap. Because the real mechanism token is placed after the ChangeCipherSpec message, the GSS-API data for the real mechanism is encrypted. If the GSS-API server is not authenticated at this point of the TLS handshake for TLSWrap, the TLSWrap context establishment MUST fail and the real authentication mechanism token MUST not be returned. The GSS-API server in turn processes the client reply and returns the TLS Finished message, the server places the reply token from the real authentication mechanism, if present, as an application data record. If additional TLS messages are needed before the application data, these additional TLS messages are encapsulated in the context token of TLSWrap in the same manner how the client hello and server hello message are encapsulated as described above. If additional tokens are required by the real authentication mechanism in order to establish the context, these tokens are placed as an application data record, encoded according to [RFC4346] and then returned as TLSWrap GSS-API context tokens, with one TLSWrap context token per each real mechanism context token. The real mechanism context tokens are decrypted by TLSWrap and then supply to the real mechanism to complete the context establishment. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 00:33:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBkBS-0002v5-RZ; Fri, 20 Jul 2007 00:33:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBkBR-0002v0-BG for tls@ietf.org; Fri, 20 Jul 2007 00:33:41 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBkBQ-0007JX-KB for tls@ietf.org; Fri, 20 Jul 2007 00:33:41 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6K4Xar3005811 for ; Fri, 20 Jul 2007 04:33:36 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6K4XaSu026354 for ; Thu, 19 Jul 2007 22:33:36 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6K4XaCi026286; Thu, 19 Jul 2007 23:33:36 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6K4XZXB026285; Thu, 19 Jul 2007 23:33:35 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 19 Jul 2007 23:33:35 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi Message-ID: <20070720043335.GA26238@Sun.COM> References: <20070719231639.GZ25464@Sun.COM> <200707192354.l6JNsPkJ029220@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707192354.l6JNsPkJ029220@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Fri, Jul 20, 2007 at 01:54:25AM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > There is no way to piggyback a 1 round-trip GSS > > context token exchange onto the full handshake pictured in figure 1 of > > RFC4346. > > This is a NO. > > I'm confused. The Finished messages provide a verifier for the entire preceding handshake. Therefore the entire preceding handshake MUST end no later than when the first finished message is sent. See Fig. 1 of RFC4346. > What I was thinking of was piggybacking the initators first context level > token onto the client's finished message and the acceptors first context > level token onto the servers finished message. If you do that then what you have isn't TLS (or you're nesting TLS, in which case you'll be having another exchange of Finished messages). > > Nor is there a way to piggiback the first context token into > > the client Hello message without first extending the client Hello, but > > how can we extend the client Hello? (AFAICS we cannot.) > > Hello extensions should work with SSLv3 already. For client hello? > Is there a size limitation on the Hello extension? > (because there is no size limitation on the gssapi context level tokens). TLS has a record size limit -- to exceed it you must fragment. > Fallback if the security context establishment fails is not > necessarily a good idea, because if you really want gss-api > based authentication and that fails for a technical reason, > you will not see the GSS-API error, but instead get a > fallback to the TLS handshake. That's up to the client. Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 00:51:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBkSv-0006UA-Kn; Fri, 20 Jul 2007 00:51:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBkSu-0006U3-Co for tls@ietf.org; Fri, 20 Jul 2007 00:51:44 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBkSt-0007Z8-Tn for tls@ietf.org; Fri, 20 Jul 2007 00:51:44 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6K4pgGo009713 for ; Fri, 20 Jul 2007 04:51:42 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6K4pgRF001307 for ; Thu, 19 Jul 2007 22:51:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6K4pgJW026311; Thu, 19 Jul 2007 23:51:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6K4pfPn026310; Thu, 19 Jul 2007 23:51:41 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 19 Jul 2007 23:51:41 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi Message-ID: <20070720045140.GC26276@Sun.COM> References: <200707192354.l6JNsPkJ029220@fs4113.wdf.sap.corp> <200707200020.l6K0KTdL000752@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707200020.l6K0KTdL000752@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Fri, Jul 20, 2007 at 02:20:29AM +0200, Martin Rex wrote: > A while back we had a discussion about changing the TLS PRF. > Then it was suggested that it should be OK if both parties have > to keep all SSL handshake messages around in order to compute > the finished messages. > > I don't think this would be a good idea if there is no size limit > on the size of the entire SSL/TLS handshake. Do we really want > to have the entire GSS-API token exchange WITHIN the TLS handshake? Well, we could have the Finished message construction modified so as to substitute a hash of each GSS context token in place of that token. > The decision of a TLS server to abort a handshake because of an > excessively large Hello extension itself might be easier than > to tell from which size on a huge optimistic context token for an > (potentially unsupported) gssapi mechanism in the SPNEGO token > should be considered an offense or attack deserving a FATAL SSL alert... I don't think we want to have the initial context token go in the client Hello message, even if it turns out that we could. I'm willing to eat that round-trip (even though I might be -- I haven't decided :) -- concerned about additional round-trips in the GSS-fails case). Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 00:56:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBkXq-0001a9-P3; Fri, 20 Jul 2007 00:56:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBkXp-0001Zx-6K for tls@lists.ietf.org; Fri, 20 Jul 2007 00:56:49 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBkXn-0004ZK-1g for tls@lists.ietf.org; Fri, 20 Jul 2007 00:56:48 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6K4ukg3007430 for ; Fri, 20 Jul 2007 04:56:46 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6K4ujc9002723 for ; Thu, 19 Jul 2007 22:56:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6K4ujAt026318; Thu, 19 Jul 2007 23:56:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6K4ujYe026317; Thu, 19 Jul 2007 23:56:45 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 19 Jul 2007 23:56:45 -0500 From: Nicolas Williams To: Larry Zhu Subject: Re: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt Message-ID: <20070720045644.GD26276@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Thu, Jul 19, 2007 at 08:43:04PM -0700, Larry Zhu wrote: > A new section is inserted in -03: the TCPWrap pseudo mechanism is > defined to describe how to TLS protect GSS-data. > > http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx > t > > 6. Protecting GSS-API Authentication Data > > GSS-API [RFC2743] provides security services to callers in a generic > fashion, supportable with a range of underlying mechanisms and > technologies and hence allowing source-level portability of > applications to different environments. For example, Kerberos is a > GSS-API mechanism defined in [RFC4121]. It is possible to design a > GSS-API mechanism that can be used with FKA-TLS in order to, for > example, provide client authentication, and is so weak that its GSS- > API token MUST NOT be in clear text over the open network. A good > example is a GSS-API mechanism that implements basic authentication. I don't think we want to have such a mechanism, ever (LIPKEY isn't it -- it relies on another mechanism to provide protection; also we'd not want to use LIPKEY-like things in TLS, ever). I think a DIGEST-MD5-type mechanism would be a much better example. And privacy protection for mechanisms that send client identities in the clear. > Although such mechanisms are unlikely to be standardized and will be > encouraged in no circumstance, they exist for practical reasons. Unlikely indeed :) > In order to provide a standard way for protecting weak GSS-API data > for use over FKA-TLS, TLSWrap is defined in this section as a pseudo > GSS-API mechanism that wraps around the real GSS-API authentication > context establishment tokens. This pseudo GSS-API mechanism does not > provide per-message security. Hmm, why not just do a TLS exchange with anon suites then nest another TLS exchange with GSS and channel binding to the first exchange? Sounds much simpler to me. (Queue Martin's comment that GSS mechs don't necessarily support channel binding, our answer to which would be that all Internet standards track GSS mechs will :) :) Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 03:42:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBn7r-0000kA-6J; Fri, 20 Jul 2007 03:42:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBn7p-0000h4-UA for tls@lists.ietf.org; Fri, 20 Jul 2007 03:42:09 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBn7p-00080k-D2 for tls@lists.ietf.org; Fri, 20 Jul 2007 03:42:09 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 20 Jul 2007 00:42:08 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.726.0; Fri, 20 Jul 2007 00:42:08 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jul 2007 00:42:08 -0700 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 Subject: RE: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt Date: Fri, 20 Jul 2007 00:41:55 -0700 Message-ID: In-Reply-To: <20070720045644.GD26276@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt Thread-Index: AcfKimS4jIOPInC8TUCndToeZ+VLkwAFthhw References: <20070720045644.GD26276@Sun.COM> From: Larry Zhu To: Nicolas Williams X-OriginalArrivalTime: 20 Jul 2007 07:42:08.0116 (UTC) FILETIME=[798CBB40:01C7CAA1] X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Nicolas.Williams wrote: > Hmm, why not just do a TLS exchange with anon suites then nest another > TLS exchange with GSS and channel binding to the first exchange? we do not want to force Kerberos to pay for the perf penalty and extra round trips. -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Thursday, July 19, 2007 9:57 PM To: Larry Zhu Cc: tls@lists.ietf.org Subject: Re: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt On Thu, Jul 19, 2007 at 08:43:04PM -0700, Larry Zhu wrote: > A new section is inserted in -03: the TCPWrap pseudo mechanism is > defined to describe how to TLS protect GSS-data. >=20 > http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx > t >=20 > 6. Protecting GSS-API Authentication Data >=20 > GSS-API [RFC2743] provides security services to callers in a generic > fashion, supportable with a range of underlying mechanisms and > technologies and hence allowing source-level portability of > applications to different environments. For example, Kerberos is a > GSS-API mechanism defined in [RFC4121]. It is possible to design a > GSS-API mechanism that can be used with FKA-TLS in order to, for > example, provide client authentication, and is so weak that its GSS- > API token MUST NOT be in clear text over the open network. A good > example is a GSS-API mechanism that implements basic authentication. I don't think we want to have such a mechanism, ever (LIPKEY isn't it -- it relies on another mechanism to provide protection; also we'd not want to use LIPKEY-like things in TLS, ever). I think a DIGEST-MD5-type mechanism would be a much better example. And privacy protection for mechanisms that send client identities in the clear. > Although such mechanisms are unlikely to be standardized and will be > encouraged in no circumstance, they exist for practical reasons. Unlikely indeed :) > In order to provide a standard way for protecting weak GSS-API data > for use over FKA-TLS, TLSWrap is defined in this section as a pseudo > GSS-API mechanism that wraps around the real GSS-API authentication > context establishment tokens. This pseudo GSS-API mechanism does not > provide per-message security. Hmm, why not just do a TLS exchange with anon suites then nest another TLS exchange with GSS and channel binding to the first exchange? Sounds much simpler to me. (Queue Martin's comment that GSS mechs don't necessarily support channel binding, our answer to which would be that all Internet standards track GSS mechs will :) :) Nico --=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 12:31:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvNb-0004Nn-JM; Fri, 20 Jul 2007 12:30:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvNa-0004Ni-IG for tls@ietf.org; Fri, 20 Jul 2007 12:30:58 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBvNZ-0002bW-0y for tls@ietf.org; Fri, 20 Jul 2007 12:30:58 -0400 Received: from [134.147.40.246] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1IBvNW3QZ0-0005Xc; Fri, 20 Jul 2007 18:30:54 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 40D471A04D; Fri, 20 Jul 2007 18:30:54 +0200 (CEST) Date: Fri, 20 Jul 2007 18:30:54 +0200 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi Message-ID: <20070720163053.GA30542@tau.invalid> References: <20070719231639.GZ25464@Sun.COM> <200707192354.l6JNsPkJ029220@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707192354.l6JNsPkJ029220@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1/b7wknhoi6tZNlypkuju1KRScJzz1HE0S7BtX sxfR/oVzQc6dMkfcgEcgJn/uKzFHpI3/elMZPOT+szCzUMDVHX oO7/QfFZb+ZcrIeb2oj38saY566WIbomD5hysrBgTwME53F1a9 3Tw== X-Spam-Score: -0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tls@ietf.org, Nicolas Williams X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Fri, Jul 20, 2007 at 01:54:25AM +0200, Martin Rex wrote: >>> If you coalesce the first GSS-API context establishment roundtrip >>> onto the TLS finished messages you have the same amount of roundtrips >>> for a TLS+rfc-1964 kerberos authentication than for a plain TLS >>> handshake. > I just noticed, that technically implementations like OpenSSL have > implemented the exchange of the Finished messages in a half-duplex > fashion. I don't know whether this is strict requirement from the > protocol or whether it is because it is easier to implement and > it wouldn't be a good idea to let the client application send data > before the server's finished message was received and verified. To protect the application data, generally you wouldn't want to start sending anything before having verified the server's Finished message. Usually, certificate-based authentication ensures that the client knows that it is talking to the proper server, i.e. only the server will have the same symmetric key material -- but still an adversary could have attacked the TLS handshake to manipulate the negotiation process. So you might be using a symmetric cipher that is less secure than intended, or even an authentication-only cipher (NULL encryption). Verifying the other party's Finished message allows both parties to detect such attacks, provided that the ciphersuite and keys in use at least do provide sufficiently strong authentication. If you don't worry about the confidentiality of the data that you are sending immediatly after encryption has started, then there is no security need to delay sending this data until having received and verified the server's Finished message. But this is an exception. A general-purpose TLS library that doesn't know anything about the application data that it has to protect really needs to wait for the Finished message. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 12:44:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvaq-0006nm-Vc; Fri, 20 Jul 2007 12:44:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvap-0006ng-HC for tls@lists.ietf.org; Fri, 20 Jul 2007 12:44:39 -0400 Received: from mail.ca.certicom.com ([38.113.160.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBvao-0002qK-98 for tls@lists.ietf.org; Fri, 20 Jul 2007 12:44:39 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 8760D10027FE6; Fri, 20 Jul 2007 08:45:50 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-MBI6dXUT9e; Fri, 20 Jul 2007 08:45:47 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP; Fri, 20 Jul 2007 08:45:47 -0400 (EDT) In-Reply-To: To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Subject: Re: [TLS] Support for TLS extensions MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Fri, 20 Jul 2007 12:40:28 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.2FP1|January 10, 2007) at 07/20/2007 12:40:30 PM, Serialize complete at 07/20/2007 12:40:30 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0040299904==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0040299904== Content-Type: multipart/alternative; boundary="=_alternative 005BF7958525731E_=" This is a multipart message in MIME format. --=_alternative 005BF7958525731E_= Content-Type: text/plain; charset="US-ASCII" We have enabled support for max_fragment_length on tls.secg.org ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com pgut001 wrote on 07/16/2007 08:17:19 AM: > >I can probably enable this extension on tls.secg.org in a day or two. > > OK, no hurry for my part since I have a two conference talks to prepare at the > moment. > > Peter. > --=_alternative 005BF7958525731E_= Content-Type: text/html; charset="US-ASCII"
We have enabled support for max_fragment_length on tls.secg.org

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

pgut001 <pgut001@cs.auckland.ac.nz> wrote on 07/16/2007 08:17:19 AM:

> >I can probably enable this extension on tls.secg.org in a day or two.
>
> OK, no hurry for my part since I have a two conference talks to prepare at the
> moment.
>
> Peter.
>
--=_alternative 005BF7958525731E_=-- --===============0040299904== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0040299904==-- From tls-bounces@lists.ietf.org Fri Jul 20 12:51:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvhZ-0004MP-2I; Fri, 20 Jul 2007 12:51:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvhY-0004MI-8n for tls@ietf.org; Fri, 20 Jul 2007 12:51:36 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBvhW-0007Bs-MB for tls@ietf.org; Fri, 20 Jul 2007 12:51:36 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id SAA10177; Fri, 20 Jul 2007 18:51:22 +0200 (MESZ) From: Martin Rex Message-Id: <200707201651.l6KGpMMu004777@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for To: lha@it.su.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Fri, 20 Jul 2007 18:51:22 +0200 (MEST) In-Reply-To: <24B64CBC-C516-4CE1-B032-ADE2580D2BF5@it.su.se> from "=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=" at Jul 19, 7 09:19:04 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= wrote: > > > I agree that there should NOT be a need for a fully configured PKI. > > > > I completely disagree on the absense of a Certificate-based server > > credential. A fallback self-signed cert is a no-brainer. > > > > Do you seriously propose to give up on a mandatory-to-implement > > authentication scheme that will provide interoperability when > > your locally-preferred authentication scheme (GSS-API) is > > unavailable. > > > > SSL started off with mandatory to implement ciphersuites in order > > to provide interoperability, and historically, these used a > > certificate-based credential. > > Yes. I think there is an requirement to not need a x509 certificate > at all to run the gssapi tls functionallity. How is this conflicting with > anything you write above ? I'm confused. We don't have a standard(s track document) yet, so currently we're discussing what potential requirements a standard for a combination of TLS encryption with GSS-API authentication should have. *I* want to see a requirement for a server credentials in order to put pressure on the interoperability aspect. Interoperability is important, and the previous specs used a certificate-based credential for this purpose. We all know pretty well that popular gssapi mechanism like Kerberos5 have a serious inter-organisation interoperability problem, and that is unlikely to go away anytime soon. So to provide interoperability from the beginning we ought to stick to the one authentication scheme that currently works best cross-organization. > > > First of all, the GSS-API mechanism should protect against replay > > attacks all by itself. Where that is insufficient, the additional > > use of GSS-API channel bindings should do the trick. > > At a first glance, the use of the SSL session ID should be sufficient. > > (unless the SSL/TLS stack uses a really braindead algorithm to > > generate SSL session IDs.) > > Replay or tunneling attacks is what I worry about. With the lack > checking of binding or folding keymaterial from gss-api into tls. > > For example, an gssapi connection done in clear can be tunneled into > a protected channel and if there is no verification that the sender/ > recviers have access to the resulting context (using gss_wrap/gss_get_mic) > there is no actual authenticaition going on. > > On real world example of this is using ssh this the gss-userauth > (not gss-userauth-with-mic), then an attacker can pick up an ftp-gss > connection to the same host and tunnel it into the ssh connection > and get logged in. Very good point. (Although I needed a few minutes to understand what you are describing.) I hadn't thought of this so far. But now as you mention it, there's a deja-vu. It think this same vulnerability that has been described for krsh and krlogin long ago. It probably affects all communication where the Kerberos gssapi authentication exchange is "in the clear" and the successor communication is not at least integrity protected with the session key from the authentication (independent of the protocol, be it some kind of RPC or network file system or rfc4559). > > Thats why I say that gss should contribute with/authenticate the key > material, either by prf or get-mic. > > Thats why I say that gss-api is not a OTP/password system, you can't > treat as it is. If only the Kerberos authentication exchange is used for authentication and there is no cryptographic link to the (application) data of the communication, then Kerberos is basically reduced to an OTP scheme, correct! With Kerberos, it remains an OTP with a specific target, but when multiple targets (services) share the same key (which is not uncommon for Kerberos on Unix and a pityful near Must on Microsoft Windows) and the authentication tokens are sent in the clear (or can be obtained by MITM or some sort of social engineering) then we have the same vulnerability as every other OTP scheme. We certainly can fix that vulnerability for gssapi mechanisms which establish a shared session key during authentication. Mixing keying material that is cryptographically bound to the GSS-API exchange into the TLS key establishment is one possible solution. But I'm sure there are many ways to skin the cat, and I'm very uncomfortable with the one proposed in the current ID. GSS_prf is (only) a partial solution. However, I just noticed that it currently suffers a fatal defect which bars its use in other standards track protocols. But that defect should be easy to fix. Still, GSS_prf is a very new optional feature, and I firmly believe we should neither completely ignore the installed base that doesn't have it, nor those mechanisms that can not easily adopt it (like SPKM&friends, which is neither fatally broken nor insecure, inspite of several problems in the spec). The problem of GSS_prf rfc-4401 is, that lacks a context attribute flag (prf_avail BOOLEAN in rfc-2743 terminology, GSS_C_PRF_FLAG bit value (512) in rfc-2744 terminology) and semantics, so that the availability of this extension can be signaled/negotiated between initiator and acceptor (similar to how integ_avail and conf_avail must be signalled/negotiated) so that the established security context correctly indicates whether this feature is available on a security context (i.e. that the implementations on both sides have confirmed to each other that it is available), and indicate the result of this negotiation through the (output) context attributes to the calling application. Other than prot_ready and trans_avail, prf_avail is not an issue of the local implemenation only. >From what I remember how the signalling of integrity and confidentiality context attriubutes/flags in Kerberos, this should be easy to specify and almost trivial to implement. Traditional GSS-API channel bindings (at least the stuff for which I have seen example usage scenarios and how it is used with FTP-GSSAPI) seem inadequate as a solution. The cryptographic binding of the gssapi message protection to the gssapi authentication has always been considered an implicit feature. We're discussing the combination of the GSS-API authentication with message protection entirely outside of GSS-API, and I don't remember any real discussions about this in CAT/Kitten before GSS_prf, which is one of the reasons what traditional GSS-API doesn't support it (the other is crypto-export politics, when GSS-API was originally designed there were strict US crypto export regulations and the GSS-API abstraction was also used to keep crypto keys out of reach of the application caller and to be able to enforce "integrity only" in spite of a shared session key as a result of the authentication. (Does anyone remember that Microsoft un-documented the "Seal/Unseal" calls in SSPI because of this?) Anyway, I would really prefer if we devise a method to use gss-api over tls with mechanism implementations that do NOT have GSS_prf for the case that is not available. I'm ok with the use of GSS_prf when the defect in rfc4401 described above is fixed and there is a requirement to use it only when the context attribute confirms that both communication peers implement GSS_prf (in an interoperable fashion, of course!) In order to establish the cryptgraphic binding, we can likely not use any "public" information in the fashion of traditional gssapi channel bindings (like network transport addresses or the SSL session ID (which I suggested)). Since the original GSS-API design sort-of protects the keying material from the application, we may need to "invent" a scheme using gss_wrap/gss_unwrap with confidentility protection. I get the feeling that we might not be able to provide a secure binding of the encrypted TLS channel with the GSS-API authentication for a mechanism that does not have GSS_prf and no confidentiality protection, and not at all for an authentication-only gssapi mechanism. TLS encryption is no pixie-dust for the misappropriated OTP token problem. Does that mean that we should discriminate against such mechanisms completely in our protocol design, trying to make them go away? Personally, I consider it unlikey that password-based authentication (disclosing as well as challenge-response) and OTP-schemes are going to be abandoned soon, and that we can speed up the process by not supporting them at all. I'm afraid it would be frowned upon for being a usability and interoperability problem with existing authentication schemes. And that would actually be true. GSS-API was specifically designed to *NOT* prevent the use of weak and broken security. Think of it as an enabling technology -- once you have switched all your applications to use existing legacy authentication schemes through GSS-API, the migration/transistion to a better and more secure authentication scheme/system will be *MUCH* easier. So there is real value in the continued support of NTLM within Microsoft Windows. I'm just disappointed about the aggressive fallbacks that have caused Microsoft to break and ship their Kerberos unnoticed on more than one occasion. Coming back to the original problem: a cryptographic binding between the GSS-API authentication and the TLS message protection: I definitely do not want to see this protocol flush the entropy from the TLS key establishment down the toilet and replace it with a (more often than not) lower entropy derived from a shared session key resulting from the gssapi authentication. Mixing both entropies would be OK, but there are probably again many ways to skin the cat. I'm all but a cryptographer. AFAIK, mixing entropy from the GSS-API authentication with the regular TLS-established pre-master secret with e.g. XOR might preserve most of what TLS has achieved for us. At the abstract level, we only need to make sure that this mixing of entropy is applied in a synchrous fashion BEFORE application data is accepted and before the TLS session is added to the session cache. However, I don't see an immediate requirement why this must happen within the TLS handshake, and can not happen after a GSS-API authentication exchange directly following the TLS handshake. We should consider the implications of our decision -- like necessary changes to our software architecture (like a protocol state machine) and modularization of our protocol implementations. I would strongly recommend to perform the GSS-API handshake entirely under TLS protection, not just to protect the clients identity, but also to prevent easy stealing of GSS-API context tokens for replay in scenarios that continue to (ab)use GSS-API in the authentication-only OTP style. > > I'm fine with introducing gss+anon-dh, but then we will get multiple > DH's in stack. But you might be just fine with that. > > gss+anon-dh will still expose the client infomation to an active > attacker in the case of gss-krb5. I prefer RSA with self-signed cert any time over anon-dh, because it enables me to (a) verify out-of-band and (b) memorize my decisions. I have more trust to other people's PGP keys on my keyring that I've verified myself on a PGP signing party or a personal encounter than any of the CA-signed S/Mime signatures. I also have more trust in the public host keys in my personal SSH known_hosts file than to any CA-signed web-server certificate which my browser considers trusted based on a list of >100 CAs and zero short-term memory. I'm well aware that my personal preferences do not scale well to the general public. With my browser, I could flush the trust anchors preconfigured by the vendor/provider and and start adding end-entity server certs according to my personal verification preferences. But the "ease of use" of the preconfigured Trust is so damn appealing to my laziness. Inappropriate and unlimited "Ease of use" might be the biggest fertilizer of security problems and computer malware. > > >> Saying SPKM doesn't support gss-psudeo random is just silly, > >> SPKM doesn't support anything, its not implementable and > >> I want better security then des/rc2. > > > > You seem to confuse the mandatory to implement symmetric ciphers > > in rfc-2025 with the stuff that really gets used in productive > > deployments. > > "Do you seriously propose to give up on a mandatory-to-implement > authentication scheme that will provide interoperability." > > rfc2025 doesn't specifify how to do padding for CONF ciphers for non > des/des3. > > INT is specififed using a stream key for des, but using rsa-sign- > for all other types. You like doing one RSA operation > per packet ? > > Everytime I look as SPKM I get sad. But this is not the right place > to talk about SPKM. It's an emirical fact we cannot deny that purely theoretical review of a spec leaves many defects. Implementors have a much better chance to find them, and ultimately independent implementors during interoperability tests. This is why there are procotol maturity levels in the IETF, and the prerequisite for draft standard are independent interoperable implementations. There were a lot of things to fix and clarify since rfc1510, and also with SPNEGO. And there are implementors that care much more about interoperability between different revisions of their own implementation than for interoperability with independent implementations of the specification. For vendors, there is unfortunately and encomonic incentive to behave this way, but this is often not in the interest of the general public. So part of the defects are regular toothing problems that are to be expected. My main criticism about SPKM and SPNEGO was their heavy use of ASN.1, which has historically been a reliable way to prevent high numbers of independent implementation and early adoption, and it probably still is a huge roadblock in theoretical review (because of a general lack of intimacy with ASN.1 among implementors. This may be attributed to the fee-based distribution model of the ASN.1 specs and the fact that it has been spread across a huge number of documents and defect reports plus not fully backwards-compatible revisioning. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 13:18:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBw7q-00005B-T4; Fri, 20 Jul 2007 13:18:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBw7p-00004v-Ih for tls@ietf.org; Fri, 20 Jul 2007 13:18:45 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBw7o-0007f4-8w for tls@ietf.org; Fri, 20 Jul 2007 13:18:45 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6KHIgT2028306 for ; Fri, 20 Jul 2007 17:18:42 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6KHIgWv021567 for ; Fri, 20 Jul 2007 11:18:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6KHIgaE026750; Fri, 20 Jul 2007 12:18:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6KHIcH9026749; Fri, 20 Jul 2007 12:18:38 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 20 Jul 2007 12:18:38 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for Message-ID: <20070720171837.GI26603@Sun.COM> References: <24B64CBC-C516-4CE1-B032-ADE2580D2BF5@it.su.se> <=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=@Jul> <200707201651.l6KGpMMu004777@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707201651.l6KGpMMu004777@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Fri, Jul 20, 2007 at 06:51:22PM +0200, Martin Rex wrote: > =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= wrote: > > > I agree that there should NOT be a need for a fully configured PKI. > > > > > > I completely disagree on the absense of a Certificate-based server > > > credential. A fallback self-signed cert is a no-brainer. If the server has a cert, then it should use it. The server can't know whether the client will or will not care. Using a cert, even a self-signed cert, has its advantages. See draft-johansson-http-tls-cb. > > > Do you seriously propose to give up on a mandatory-to-implement > > > authentication scheme that will provide interoperability when > > > your locally-preferred authentication scheme (GSS-API) is > > > unavailable. > > > > > > SSL started off with mandatory to implement ciphersuites in order > > > to provide interoperability, and historically, these used a > > > certificate-based credential. > > > > Yes. I think there is an requirement to not need a x509 certificate > > at all to run the gssapi tls functionallity. How is this conflicting with > > anything you write above ? I would think that this work is not about obviating the need for an x.509 server cert, but about providing an alternate way of authenticating either or both of the client and the server to the other. The use of an x.509 cert by either party should not be precluded by the use of the GSS-API; it should merely be made unnecessary. > I'm confused. > > We don't have a standard(s track document) yet, so currently we're > discussing what potential requirements a standard for a combination of > TLS encryption with GSS-API authentication should have. That's true. We should come up with a set of requirements, but I don't think we necessarily need a separate doc to record these requirements (just in case others do). > *I* want to see a requirement for a server credentials in order > to put pressure on the interoperability aspect. Interoperability > is important, and the previous specs used a certificate-based > credential for this purpose. We all know pretty well that > popular gssapi mechanism like Kerberos5 have a serious > inter-organisation interoperability problem, and that is > unlikely to go away anytime soon. So to provide interoperability > from the beginning we ought to stick to the one authentication > scheme that currently works best cross-organization. So why bother with this doc then? Why not just say: "if you want to use TLS then deploy a PKI?" (And to the question of where to store user creds, one answer that comes to mind would be kx509, another would be SACRED.) No, we want this work because in some environments you don't want to have to bother with PKI when you already have Kerberos V or something else. Hand-waving about "serious inter-organisation interoperability" problems in Kerberos V isn't a serious argument for requiring that a server-side x.509 cert always be used when the GSS-API is used as well. > > On real world example of this is using ssh this the gss-userauth > > (not gss-userauth-with-mic), then an attacker can pick up an ftp-gss > > connection to the same host and tunnel it into the ssh connection > > and get logged in. > > > Very good point. (Although I needed a few minutes to understand > what you are describing.) The SSHv2 thing was about channel binding -- we needed to bind the GSS-API authentication to the SSHv2 session's initial key exchange and algorithm negotiation. The SSHv2 work did not use the channel binding facility of the GSS-API; instead it used MIC tokens to achieve much the same effect. > I hadn't thought of this so far. > > But now as you mention it, there's a deja-vu. It think this same > vulnerability that has been described for krsh and krlogin long ago. Can't have been: there's no channel to bind there. The issue is related though (see below). The problem in the SSHv2 case was that an active attacker could act as an MITM (though this might depend on the user answering "yes" to the unknown hostkey question; but users always say yes to the "are you sure you want to give all your money to this guy?" dialogs). By binding the GSS-API context to the SSHv2 session the server could ensure that there was no MITM. See below. > It probably affects all communication where the Kerberos gssapi > authentication exchange is "in the clear" and the successor > communication is not at least integrity protected with the > session key from the authentication (independent of the protocol, > be it some kind of RPC or network file system or rfc4559). Right, if you use krsh/krlogin/telnet you want to ensure that you don't merely authenticate but that you protect the whole session also (rlogin -x ...). But really, you shouldn't use krsh/krlogin/telnet -- just use SSHv2. By not doing channel binding in SSHv2 what was happening is that we had the equivalent of using the GSS-API only for authentication and not for protecting the whole session. Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 13:43:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwVQ-0002gx-M3; Fri, 20 Jul 2007 13:43:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwVP-0002fK-CX for tls@ietf.org; Fri, 20 Jul 2007 13:43:07 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBwVO-0008Ab-RI for tls@ietf.org; Fri, 20 Jul 2007 13:43:07 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA22723; Fri, 20 Jul 2007 19:40:34 +0200 (MESZ) From: Martin Rex Message-Id: <200707201740.l6KHeYgH008101@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 20 Jul 2007 19:40:34 +0200 (MEST) In-Reply-To: <20070720171837.GI26603@Sun.COM> from "Nicolas Williams" at Jul 20, 7 12:18:38 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Martin.Rex@sap.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Nicolas Williams wrote: > > > *I* want to see a requirement for a server credentials in order > > to put pressure on the interoperability aspect. Interoperability > > is important, and the previous specs used a certificate-based > > credential for this purpose. We all know pretty well that > > popular gssapi mechanism like Kerberos5 have a serious > > inter-organisation interoperability problem, and that is > > unlikely to go away anytime soon. So to provide interoperability > > from the beginning we ought to stick to the one authentication > > scheme that currently works best cross-organization. > > So why bother with this doc then? Why not just say: "if you want to use > TLS then deploy a PKI?" (And to the question of where to store user > creds, one answer that comes to mind would be kx509, another would be > SACRED.) What I meant (and forgot to add) was "certificate-based credential (self-signed when no PKI is used) as a mandatory to implement feature for interoperability". If support of cert-based credentials is a mere MAY, then I am sure there will be servers/services where installing or using a PKI credential is impossible/defective/unusable, and you cannot complain to the vendor because not-supporting it is fully compliant with the spec. Everyone will be happy when Kerberos can be used cross-organization one day. But until that day, I want to make sure that the customer has the working alternative to use PKI when there is a need for it. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 13:50:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwcz-0000u0-8j; Fri, 20 Jul 2007 13:50:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwcy-0000tv-KQ for tls@ietf.org; Fri, 20 Jul 2007 13:50:56 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBwcy-0008JP-8t for tls@ietf.org; Fri, 20 Jul 2007 13:50:56 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6KHotAh011420 for ; Fri, 20 Jul 2007 17:50:55 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6KHotiY009472 for ; Fri, 20 Jul 2007 11:50:55 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6KHotYg026806; Fri, 20 Jul 2007 12:50:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6KHosjT026805; Fri, 20 Jul 2007 12:50:54 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 20 Jul 2007 12:50:53 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for Message-ID: <20070720175053.GL26603@Sun.COM> References: <20070720171837.GI26603@Sun.COM> <200707201740.l6KHeYgH008101@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707201740.l6KHeYgH008101@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Fri, Jul 20, 2007 at 07:40:34PM +0200, Martin Rex wrote: > What I meant (and forgot to add) was "certificate-based credential > (self-signed when no PKI is used) as a mandatory to implement > feature for interoperability". > > If support of cert-based credentials is a mere MAY, then I am sure > there will be servers/services where installing or using a PKI > credential is impossible/defective/unusable, and you cannot complain > to the vendor because not-supporting it is fully compliant with the spec. I don't think this spec aims to change TLS 1.1 to make any current cipher suites that are REQUIRED to implement no longer REQUIRED to implement. Nor would I support that, for interop reasons, of course. Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 13:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwhJ-00057n-15; Fri, 20 Jul 2007 13:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwhI-00056n-Ky for tls@ietf.org; Fri, 20 Jul 2007 13:55:24 -0400 Received: from ms-smtp-02.rdc-nyc.rr.com ([24.29.109.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBwhH-0004Bl-78 for tls@ietf.org; Fri, 20 Jul 2007 13:55:24 -0400 Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-02.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id l6KHtMsh008459 for ; Fri, 20 Jul 2007 13:55:22 -0400 (EDT) Received: from [128.237.242.180] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.6.0) with ESMTP id md50000058328.msg for ; Fri, 20 Jul 2007 13:56:32 -0400 Message-ID: <46A0F72F.40800@secure-endpoints.com> Date: Fri, 20 Jul 2007 13:55:59 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: martin.rex@sap.com Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for References: <200707201740.l6KHeYgH008101@fs4113.wdf.sap.corp> In-Reply-To: <200707201740.l6KHeYgH008101@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://pgp.mit.edu X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Fri, 20 Jul 2007 13:56:32 -0400 (not processed: message from valid local sender) X-MDRemoteIP: 128.237.242.180 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: tls@ietf.org, Nicolas Williams X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com 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: , Content-Type: multipart/mixed; boundary="===============1665615357==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1665615357== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000108070004000400030902" This is a cryptographically signed message in MIME format. --------------ms000108070004000400030902 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin Rex wrote: > What I meant (and forgot to add) was "certificate-based credential > (self-signed when no PKI is used) as a mandatory to implement > feature for interoperability". > > If support of cert-based credentials is a mere MAY, then I am sure > there will be servers/services where installing or using a PKI > credential is impossible/defective/unusable, and you cannot complain > to the vendor because not-supporting it is fully compliant with the spec. > > Everyone will be happy when Kerberos can be used cross-organization > one day. But until that day, I want to make sure that the customer > has the working alternative to use PKI when there is a need for it. Let me rephrase what you want: * You do not want to require that a server certificate be used when a TLS_GSS cipher is selected * You do want to require that all TLS implementations support for the certificate based ciphers Note that while we can standardize implementation requirements, we cannot standardize the deployment requirements. No one that is promoting TLS GSS wants to eliminate the use of certificate based TLS ciphers. The purpose of adding the TLS GSS ciphers is to provide a solution for environments that certificate management costs exceed the costs of the pre-existing infrastructure. Jeffrey Altman --------------ms000108070004000400030902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA3MjAxNzU1NTlaMCMGCSqGSIb3DQEJBDEWBBRdDFAP Fh6vBOsrKbbM8cE5uB42qzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAY/oIeYp0Pgk5OjWGUM+XXuetYWxKhG5Mj8FdUS3e6jqjBYzRiv9n zp3ttjyAlPJFCYXZ2QS2zJiTaYc+dgkBcIygZx+iEyMnNsUKCgLwo2/1mIGejy/5sHnLFWa6 stooDfCAelrch55SyoZjrsfu2gHR3TKrSGft6EOey/fa5DEkzN+lX1wQPtlOE5TQmMmUruHM qBq+VHPDaczGJcBgVQwVekq0T53ZWQKMH3138XJWFbCQ04zPYujHmxhUopV1mVDFQZxvWrLQ LWReAOfZF8t51XU+7aao4Tyhnxj9ur/pUY156c3q/9FwufyoWmerd8UqNMtgOvB2fH7VaQLu uQAAAAAAAA== --------------ms000108070004000400030902-- --===============1665615357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1665615357==-- From tls-bounces@lists.ietf.org Fri Jul 20 14:19:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBx4f-0006EH-B7; Fri, 20 Jul 2007 14:19:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBx4d-00063I-Vl for tls@ietf.org; Fri, 20 Jul 2007 14:19:32 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBx4d-0000Np-BA for tls@ietf.org; Fri, 20 Jul 2007 14:19:31 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id UAA21064; Fri, 20 Jul 2007 20:19:24 +0200 (MESZ) From: Martin Rex Message-Id: <200707201819.l6KIJOFW010809@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 20 Jul 2007 20:19:24 +0200 (MEST) In-Reply-To: <20070720175053.GL26603@Sun.COM> from "Nicolas Williams" at Jul 20, 7 12:50:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Martin.Rex@sap.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Nicolas Williams wrote: > > On Fri, Jul 20, 2007 at 07:40:34PM +0200, Martin Rex wrote: > > What I meant (and forgot to add) was "certificate-based credential > > (self-signed when no PKI is used) as a mandatory to implement > > feature for interoperability". > > > > If support of cert-based credentials is a mere MAY, then I am sure > > there will be servers/services where installing or using a PKI > > credential is impossible/defective/unusable, and you cannot complain > > to the vendor because not-supporting it is fully compliant with the spec. > > I don't think this spec aims to change TLS 1.1 to make any current > cipher suites that are REQUIRED to implement no longer REQUIRED to > implement. Nor would I support that, for interop reasons, of course. This isn't about what the TLS implementation supports, but what subset of the TLS implementations features a server/service is able to use. The hard part of the work isn't the code, it is the configuration and administrative UI stuff. As I wrote in previous Emails, I think the gssapi-over-tls authentication should be put into a module "TLSplus" above a mostly vanilla TLS and next to completely vanilla GSS-API and look like a normal TLS for the application caller. Implementors will probably use different approaches, some will not provide seperate module and not be able to plug'n'play gssapi mechanisms. Others may want to offer exactly this modularization, and especially the gss-api plug'n'play. For the architecture I've been trying to describe, ABI issues and binary plug'n'play is fairly easy compared to the interoperability issues among independent implementations (at least if you do a certain level of QA on the API -- tough luck, Solaris Kerberos included SunOS 5.9 still contains numerous API-level bugs in the GSS-API they should consider adopting several 10-year old fixes from MIT Kerberos GSS-API). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 14:21:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBx6U-0008Hd-GA; Fri, 20 Jul 2007 14:21:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBx6T-0008G0-Jy for tls@ietf.org; Fri, 20 Jul 2007 14:21:25 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBx6S-0004h3-JH for tls@ietf.org; Fri, 20 Jul 2007 14:21:25 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6KILNAS003182 for ; Fri, 20 Jul 2007 18:21:23 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6KILN46023103 for ; Fri, 20 Jul 2007 12:21:23 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6KILNFZ026906; Fri, 20 Jul 2007 13:21:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6KILNxG026905; Fri, 20 Jul 2007 13:21:23 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 20 Jul 2007 13:21:22 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for Message-ID: <20070720182122.GM26603@Sun.COM> References: <20070720175053.GL26603@Sun.COM> <200707201819.l6KIJOFW010809@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707201819.l6KIJOFW010809@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Fri, Jul 20, 2007 at 08:19:24PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > On Fri, Jul 20, 2007 at 07:40:34PM +0200, Martin Rex wrote: > > > What I meant (and forgot to add) was "certificate-based credential > > > (self-signed when no PKI is used) as a mandatory to implement > > > feature for interoperability". > > > > > > If support of cert-based credentials is a mere MAY, then I am sure > > > there will be servers/services where installing or using a PKI > > > credential is impossible/defective/unusable, and you cannot complain > > > to the vendor because not-supporting it is fully compliant with the spec. > > > > I don't think this spec aims to change TLS 1.1 to make any current > > cipher suites that are REQUIRED to implement no longer REQUIRED to > > implement. Nor would I support that, for interop reasons, of course. > > This isn't about what the TLS implementation supports, but what > subset of the TLS implementations features a server/service > is able to use. See Jeff's point about implementation versus deployment. We could require the use of a self-signed cert if no PKI is available, but, why? (I gave an answer, of course, related to draft-johansson-http-tls-cb). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 14:28:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxDh-0005cP-EQ; Fri, 20 Jul 2007 14:28:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxDg-0005cJ-FH for tls@ietf.org; Fri, 20 Jul 2007 14:28:52 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBxDf-0004qo-2x for tls@ietf.org; Fri, 20 Jul 2007 14:28:52 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id UAA03496; Fri, 20 Jul 2007 20:28:25 +0200 (MESZ) From: Martin Rex Message-Id: <200707201828.l6KISQgI011525@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for To: jaltman@secure-endpoints.com Date: Fri, 20 Jul 2007 20:28:26 +0200 (MEST) In-Reply-To: <46A0F72F.40800@secure-endpoints.com> from "Jeffrey Altman" at Jul 20, 7 01:55:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Nicolas.Williams@sun.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Jeffrey Altman wrote: > > Martin Rex wrote: > > What I meant (and forgot to add) was "certificate-based credential > > (self-signed when no PKI is used) as a mandatory to implement > > feature for interoperability". > > > > If support of cert-based credentials is a mere MAY, then I am sure > > there will be servers/services where installing or using a PKI > > credential is impossible/defective/unusable, and you cannot complain > > to the vendor because not-supporting it is fully compliant with the spec. > > > > Everyone will be happy when Kerberos can be used cross-organization > > one day. But until that day, I want to make sure that the customer > > has the working alternative to use PKI when there is a need for it. > Let me rephrase what you want: > > * You do not want to require that a server certificate be used when a > TLS_GSS cipher is selected Nope. I completely dislike the lack of orthogonality to TLS on this issue. I do NOT want the gssapi-over-tls require any particular ciphersuite (instead work with those that are there and future ones), and in particular I do this spec NOT want to define a new cipher suite. > > * You do want to require that all TLS implementations support for the > certificate based ciphers I want a mandatory to implement subset of ciphersuites. SSLv3 had this and from what Nico says, TLSv1.1 might still have it. (I'm behind on TLS evlutionary changes). > > Note that while we can standardize implementation requirements, we > cannot standardize the deployment requirements. We can not require which buttons the customer presses on installation, but we can require which buttons must be available to the customer for installation/configuration. > > No one that is promoting TLS GSS wants to eliminate the use of > certificate based TLS ciphers. The purpose of adding the TLS GSS > ciphers is to provide a solution for environments that certificate > management costs exceed the costs of the pre-existing infrastructure. I have _never_ disputed this motivation. And I certainly do not want to take this freedom away from the customer. However, I clearly want to deny the vendor a compliance tag for not providing a fully functional option to the customer. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 14:45:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxTb-0001zy-HT; Fri, 20 Jul 2007 14:45:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxTa-0001zl-3S for tls@ietf.org; Fri, 20 Jul 2007 14:45:18 -0400 Received: from ms-smtp-02.rdc-nyc.rr.com ([24.29.109.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBxTZ-0007WH-Pi for tls@ietf.org; Fri, 20 Jul 2007 14:45:18 -0400 Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-02.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id l6KIjEcE013488 for ; Fri, 20 Jul 2007 14:45:14 -0400 (EDT) Received: from [128.237.242.180] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.6.0) with ESMTP id md50000058347.msg for ; Fri, 20 Jul 2007 14:46:23 -0400 Message-ID: <46A102E1.9060108@secure-endpoints.com> Date: Fri, 20 Jul 2007 14:45:53 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: martin.rex@sap.com Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for References: <200707201828.l6KISQgI011525@fs4113.wdf.sap.corp> In-Reply-To: <200707201828.l6KISQgI011525@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://pgp.mit.edu X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Fri, 20 Jul 2007 14:46:23 -0400 (not processed: message from valid local sender) X-MDRemoteIP: 128.237.242.180 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: tls@ietf.org, Nicolas.Williams@sun.com X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com 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: , Content-Type: multipart/mixed; boundary="===============0004836914==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0004836914== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080509090804070103020900" This is a cryptographically signed message in MIME format. --------------ms080509090804070103020900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin Rex wrote: > I have _never_ disputed this motivation. And I certainly do not > want to take this freedom away from the customer. However, I clearly > want to deny the vendor a compliance tag for not providing a fully > functional option to the customer. Martin: That is exactly what mandatory to implement means. The vendor must implement it to be considered in compliance. However, you can't mandate in an IETF standard what is deployed by the users of the implementation. My requirement is that TLS be deployable without certificates if an alternative mechanism for managing keys distribution is available. I have that today with RFC 2712. Jeffrey Altman --------------ms080509090804070103020900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA3MjAxODQ1NTNaMCMGCSqGSIb3DQEJBDEWBBT+vH1Q Nk8RDzC+xA7zjIwmV+vdXTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEACmrvtAOPcQrugCMrFNIfq5CQo6c1iZl4ObuXZYe/1eh9uOGik5Ry oWUFuxnRc/UheXo4vpWM9l7qpmAsdouxKdabvGDbGc3G2RGIKHyyaK7Ke76WCPZufHD/EpLy 4QWNgRg5RN3mom44DGVTbjDDcxlRU0fnlsrbOqFxvmF73JpCfswpHwO/62/18+Bb3TYQBLrL A6E//XkIhLjqYGBV44I7oWH+aO14z6JO1rNqTOHFeYacfOedFoCF2HXz57MgRYSnNu2/kEsH WLQ8PbrZU7eCY1VGEXwTSu+yOARGDFdN8tX8Iyu+eF5hGnaLwzTzw+5qj0w3+Y6NcpM/Fb9q LwAAAAAAAA== --------------ms080509090804070103020900-- --===============0004836914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0004836914==-- From tls-bounces@lists.ietf.org Fri Jul 20 14:49:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxXs-000616-8M; Fri, 20 Jul 2007 14:49:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxXq-00060z-C0 for tls@ietf.org; Fri, 20 Jul 2007 14:49:42 -0400 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBxXp-0005Mo-QM for tls@ietf.org; Fri, 20 Jul 2007 14:49:42 -0400 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l6KInfQq028642 for ; Fri, 20 Jul 2007 14:49:41 -0400 (EDT) Received: from 144.51.60.33 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Fri, 20 Jul 2007 14:49:41 -0400 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jul 2007 14:49:41 -0400 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 Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for Date: Fri, 20 Jul 2007 14:49:25 -0400 Message-ID: In-Reply-To: <200707201651.l6KGpMMu004777@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] the use cases for GSS-based TLS and the plea for Thread-Index: AcfK75yYRS1r0Fz+R4mO7zWqJ14pCQACN9gQ References: =?iso-8859-1?Q?=3C24B64CBC-C516-4CE1-B032-ADE2580D2BF5=40it=2Esu=2Ese=3E_?= =?iso-8859-1?Q?from=22Love_H=F6rnquist_=C5strand=22_at_Jul_19=2C7_09=3A19?= =?iso-8859-1?Q?=3A04_pm_=3C200707201651=2El6KGpMMu004777=40fs4113=2Ew?= =?iso-8859-1?Q?df=2Esap=2Ecorp=3E?= From: "Kemp, David P." To: X-OriginalArrivalTime: 20 Jul 2007 18:49:41.0237 (UTC) FILETIME=[BB11FA50:01C7CAFE] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15310000 X-TM-AS-Result: : Yes--2.074100-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTEzOTAwNi03MDAw?= =?us-ascii?B?NzMtNzAwMzE2LTcxMDIwNy03MDE1NzYtNzEwOTcwLTE4ODAxOS03?= =?us-ascii?B?MDAzMDAtNzA0ODUyLTcwNDQzMC03MDE0NjQtNzAyMzU4LTcwMjcy?= =?us-ascii?B?Ni03MDE2MTgtNzA2MjcxLTcwNjQ4NC03MDEyMDItNzAwNTQ2LTcx?= =?us-ascii?B?MDUxMi03MDE1OTQtNzEwMDYyLTcwMTY3NC03MDY4MjMtNzA1NDI0?= =?us-ascii?B?LTcwMDQ3Ni03MDE4MzctMTIxNDE0LTE4ODEyMS03MDU1ODQtMTIx?= =?us-ascii?B?NjQwLTEzOTcwNC03MDgxOTYtNzAwMjcyLTcwMjA1MC03MDQ0OTYt?= =?us-ascii?B?MTA2NTgwLTcwNjc2OS0xMDU2MzAtNzA5NTEyLTcwMjc2Mi03MDIx?= =?us-ascii?B?OTItMTM5NzAzLTcwMDM0Mi0xNDgwMzktMTQ4MDUw?= X-Spam-Score: -1.0 (-) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org -----Original Message----- From: Martin Rex [mailto:Martin.Rex@sap.com]=20 Sent: Friday, July 20, 2007 12:51 PM [Many excellent points and much cogent discussion snipped ...] So part of the defects are regular toothing problems that are to be expected. My main criticism about SPKM and SPNEGO was their heavy use of ASN.1, which has historically been a reliable way to prevent high numbers of independent implementation and early adoption, and it probably still is a huge roadblock in theoretical review (because of a general lack of intimacy with ASN.1 among implementors. This may be attributed to the fee-based distribution model of the ASN.1 specs and the fact that it has been spread across a huge number of documents and defect reports plus not fully backwards-compatible revisioning. -----End Original Message----- It seems strange to criticize SPKM and SPNEGO for being ASN.1-based while not making the same criticism of Kerberos. To what extent has the adoption and theoretical review of Kerberos been hampered by this "huge" roadblock? And of course, SNMP (http://www.ibr.cs.tu-bs.de/~schoenw/papers/sane-2002.pdf) has been a huge failure in the marketplace for the same reasons :-) I don't disagree that the learning curve for ASN.1 is steeper than for bits-in-boxes (http://www.ietf.org/rfc/rfc791.txt). But anyone who wishes to learn has open source software to look at, as well as the ability to obtain free copies of ITU specs (no registration required, no more limit of 3 freebies per year), including X.680 http://www.itu.int/rec/T-REC-X.680-200207-I/en. Dave _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 14:54:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxcH-00018r-0V; Fri, 20 Jul 2007 14:54:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxcG-00018l-38 for tls@ietf.org; Fri, 20 Jul 2007 14:54:16 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBxcF-0007iJ-GZ for tls@ietf.org; Fri, 20 Jul 2007 14:54:16 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id UAA19219; Fri, 20 Jul 2007 20:54:11 +0200 (MESZ) From: Martin Rex Message-Id: <200707201854.l6KIsBUo013002@fs4113.wdf.sap.corp> Subject: Re: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt To: lzhu@windows.microsoft.com (Larry Zhu) Date: Fri, 20 Jul 2007 20:54:11 +0200 (MEST) In-Reply-To: from "Larry Zhu" at Jul 19, 7 08:48:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Larry Zhu wrote: > > A new section is inserted in -03: the TCPWrap pseudo mechanism is > defined to describe how to TLS protect GSS-data. > > http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.txt > > 6. Protecting GSS-API Authentication Data To me it looks like this is going into the wrong direction. There is a saying: "Perfection [in design] is achieved not when there is nothing left to add, but rather when there is nothing left to take away." Actually, there is a requirement for advancing protocol specs on the standards track that follows this spirit. Feature creep is one of the reasons why more and more IETF standards lately revision&cycle on proposed status instead of advancing to draft. I believe this will hurt us in the long run. My suggested architecture is intended to fly with an installed base legacy gssapi implementation and with as little changes to TLS as is humanely possible, then entire mechanism negotiation in a fairly generic and small Hello extension plus a new container content type to carry the GSSAPI handshake following the TLS handshake. TLS will never ever touch, know or care about gssapi mechanisms, gssapi functions, gssapi object handles, gssapi naming or gssapi extensions. I firmly believe we can obivate SPNEGO in this protocol entirely, as well as any kind of mechglue stuff. In contrast to this, the current ID: - requires the use of specific ciphersuites - defines new ciphersuites - requires a new and optional feature from the gssapi mechanism that close to none of the installed base of mechanism has and that many mechanisms can not easily or not at all provide - requires SPNEGO for negotiation of mechanism. - requires massive changes to the entire TLS state machine - inflates the size and processing time of the entire TLS handshake - leaves it completely in the mist how to extort gssapi handles that TLS will need to perform a gssapi context establishment durint the TLS hanshake available to the application caller to make any GSS-API extensions (names,attributes,authorizations) accessible to the application caller - you just came up with yet another pseudo-mechanism in order to protect the gssapi token exchange -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 15:09:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxql-0005uF-Tx; Fri, 20 Jul 2007 15:09:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxqk-0005u6-NO for tls@ietf.org; Fri, 20 Jul 2007 15:09:14 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBxqj-00081x-Va for tls@ietf.org; Fri, 20 Jul 2007 15:09:14 -0400 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Fri, 20 Jul 2007 12:09:12 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.726.0; Fri, 20 Jul 2007 12:09:08 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jul 2007 12:09:08 -0700 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 Subject: RE: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt Date: Fri, 20 Jul 2007 12:08:40 -0700 Message-ID: In-Reply-To: <200707201854.l6KIsBUo013002@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt Thread-Index: AcfK/3DoEkLUbOnHTgSh3kJnfDX73wAABy/A References: from "Larry Zhu" at Jul 19, 7 08:48:43 pm <200707201854.l6KIsBUo013002@fs4113.wdf.sap.corp> From: Larry Zhu To: X-OriginalArrivalTime: 20 Jul 2007 19:09:08.0637 (UTC) FILETIME=[72E514D0:01C7CB01] X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > In contrast to this, the current ID: > - requires the use of specific ciphersuites Hum? Which specific ciphersuites are required? > - defines new ciphersuites Where is the definition? > - requires a new and optional feature from the gssapi mechanism that close to none of the installed base of mechanism has and that many mechanisms can not easily or not at all provide where is the requirement? > - requires SPNEGO for negotiation of mechanism. I do not see this requirement either > - requires massive changes to the entire TLS state machine Please quantify. FKA-TLS just defines a new way to derive the PSK. > - inflates the size and processing time of the entire TLS handshake Please quantify. On the contrary, we expect the size to be reduced because we do not need to send the certificates bags if FKA-TLS is negotiated, and the process time will be reduced because Kerberos is a lot faster. > - leaves it completely in the mist how to extort gssapi handles > that TLS will need to perform a gssapi context establishment > durint the TLS hanshake available to the application caller > to make any GSS-API extensions (names,attributes,authorizations) > accessible to the application caller Why do we care? > - you just came up with yet another pseudo-mechanism in order > to protect the gssapi token exchange It is an option to address your concern. It is not required to implement. I do not think it is needed. It is there illustrate how the protection can be done. --larry -----Original Message----- From: Martin Rex [mailto:Martin.Rex@sap.com]=20 Sent: Friday, July 20, 2007 11:54 AM To: Larry Zhu Cc: tls@ietf.org Subject: Re: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt Larry Zhu wrote: >=20 > A new section is inserted in -03: the TCPWrap pseudo mechanism is > defined to describe how to TLS protect GSS-data. >=20 > http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx t >=20 > 6. Protecting GSS-API Authentication Data To me it looks like this is going into the wrong direction. There is a saying: "Perfection [in design] is achieved not when there is nothing left to add, but rather when there is nothing left to take away." Actually, there is a requirement for advancing protocol specs on the standards track that follows this spirit. Feature creep is one of the reasons why more and more IETF standards lately revision&cycle on proposed status instead of advancing to draft. I believe this will hurt us in the long run. My suggested architecture is intended to fly with an installed base legacy gssapi implementation and with as little changes to TLS as is humanely possible, then entire mechanism negotiation in a fairly generic and small Hello extension plus a new container content type to carry the GSSAPI handshake following the TLS handshake. TLS will never ever touch, know or care about gssapi mechanisms, gssapi functions, gssapi object handles, gssapi naming or gssapi extensions. I firmly believe we can obivate SPNEGO in this protocol entirely, as well as any kind of mechglue stuff. In contrast to this, the current ID: - requires the use of specific ciphersuites - defines new ciphersuites - requires a new and optional feature from the gssapi mechanism that close to none of the installed base of mechanism has and that many mechanisms can not easily or not at all provide - requires SPNEGO for negotiation of mechanism. - requires massive changes to the entire TLS state machine - inflates the size and processing time of the entire TLS handshake - leaves it completely in the mist how to extort gssapi handles that TLS will need to perform a gssapi context establishment durint the TLS hanshake available to the application caller to make any GSS-API extensions (names,attributes,authorizations) accessible to the application caller - you just came up with yet another pseudo-mechanism in order to protect the gssapi token exchange -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 15:12:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxtk-000719-2I; Fri, 20 Jul 2007 15:12:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxti-000712-LK for tls@ietf.org; Fri, 20 Jul 2007 15:12:18 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBxti-0005tw-71 for tls@ietf.org; Fri, 20 Jul 2007 15:12:18 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id VAA17031; Fri, 20 Jul 2007 21:12:14 +0200 (MESZ) From: Martin Rex Message-Id: <200707201912.l6KJCE7Y014140@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Fri, 20 Jul 2007 21:12:14 +0200 (MEST) In-Reply-To: from "Kemp, David P." at Jul 20, 7 02:49:25 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Kemp, David P. wrote: > > It seems strange to criticize SPKM and SPNEGO for being ASN.1-based > while not making the same criticism of Kerberos. To what extent > has the adoption and theoretical review of Kerberos been hampered > by this "huge" roadblock? When ASN.1 was less of a problem, then the ambiguity about the AlgOID within PKCS#1 would not have been earlier detected, it would not even exist! Or you may want to look at the pity the PKI guys created with certificate chains in ASN.1 containers (SOAP/WS-Security). The PKI guys messed abused PKCS#7 containers and CertificatePairs until they finally came up with a PKIPath. The text of the defect report describing PKIPath (not easy to find) is much better than what was added to the spec document. But both do not say a word whether a self-signed RootCA certs is either prohibited, allowed, expected, required. TLSv1.0 already recognized this ambiguity in SSLv3 and fixed it long ago. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 16:15:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBysX-0007t7-Vp; Fri, 20 Jul 2007 16:15:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBysW-0007sd-3g for tls@ietf.org; Fri, 20 Jul 2007 16:15:08 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBysV-00076c-H8 for tls@ietf.org; Fri, 20 Jul 2007 16:15:08 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id WAA03161; Fri, 20 Jul 2007 22:15:03 +0200 (MESZ) From: Martin Rex Message-Id: <200707202015.l6KKF4S7018562@fs4113.wdf.sap.corp> Subject: Re: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt To: lzhu@windows.microsoft.com (Larry Zhu) Date: Fri, 20 Jul 2007 22:15:04 +0200 (MEST) In-Reply-To: from "Larry Zhu" at Jul 20, 7 12:08:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Larry Zhu wrote: > > Martin Rex wrote: > > In contrast to this, the current ID: > > - requires the use of specific ciphersuites > > Hum? Which specific ciphersuites are required? > > > - defines new ciphersuites > > Where is the definition? Unless I missed the TLS working groups rough consensus to add PSK ciphersuites as a mandatory to implement ciphersuite into TLS 1.2 it counts as a new (and specific) ciphersuite for all versions of TLS. It definitely counts as new for older versions of TLS. (Was it Nico who used a distinct ciphersuite ID TLS_GSS when talking about the current draft?) Repeating myself, orthogonality to TLS is one of things I'm favouring, which means that my conceived architecture should fly just fine as an extension to TLSv1.1, TLSv1.0 and even SSLv3. > > > - requires a new and optional feature from the gssapi mechanism > that close to none of the installed base of mechanism has > and that many mechanisms can not easily or not at all provide > > where is the requirement? > > > - requires SPNEGO for negotiation of mechanism. > > I do not see this requirement either I'm sorry if I have been jumping to a wrong conclusion too fast. Nico started the thread "[TLS] Negotiation in draft-santesson-tls-gssapi" asking for how you intend to select for a common gssapi mechanism asserting that you would need either SPNEGO or an alternative means. I may have wrongly interpreted your silence to this question (incomparison to the two appendix you have posted upon other questions) as an indication that you didn't want to supply an alternative to SPNEGO. > > > - requires massive changes to the entire TLS state machine > > Please quantify. FKA-TLS just defines a new way to derive the PSK. new messages (=states) within the existing TLS handshake? > > > - inflates the size and processing time of the entire TLS handshake > > Please quantify. On the contrary, we expect the size to be reduced > because we do not need to send the certificates bags if FKA-TLS is > negotiated, and the process time will be reduced because Kerberos is a > lot faster. I don't know what size your typical certs and cert paths are, but ALL security context establishment tokens (combined) of the ~20 gssapi mechanism I've seen (except NTLM) beat the typical server certificate messsage size by at least a factor of 3. > > > - leaves it completely in the mist how to extort gssapi handles > > that TLS will need to perform a gssapi context establishment > > durint the TLS hanshake available to the application caller > > to make any GSS-API extensions (names,attributes,authorizations) > > accessible to the application caller > > Why do we care? Maybe because of the KISS principle? > > > - you just came up with yet another pseudo-mechanism in order > > to protect the gssapi token exchange > > It is an option to address your concern. It is not required to > implement. I do not think it is needed. It is there illustrate how the > protection can be done. I wouldn't mind if on some questions you would answer: oh, for this we could just use the following existing protocol feature, which everyone supports already because it has been mandatory to implement, and we don't even need to change anything. ;-) -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 16:55:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBzVA-0002kI-DW; Fri, 20 Jul 2007 16:55:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBzV9-0002kD-8h for tls@ietf.org; Fri, 20 Jul 2007 16:55:03 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBzV7-0007uD-NS for tls@ietf.org; Fri, 20 Jul 2007 16:55:03 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id C7F1E7410A; Fri, 20 Jul 2007 22:55:00 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26701-01-32; Fri, 20 Jul 2007 22:55:00 +0200 (CEST) Received: from [83.188.169.224] (m83-188-169-224.cust.tele2.se [83.188.169.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id A5E6A740F2; Fri, 20 Jul 2007 22:54:58 +0200 (CEST) Message-ID: <46A12124.4020000@it.su.se> Date: Fri, 20 Jul 2007 22:55:00 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: martin.rex@sap.com Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for References: <200707201740.l6KHeYgH008101@fs4113.wdf.sap.corp> In-Reply-To: <200707201740.l6KHeYgH008101@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.283 tagged_above=-99 required=7 tests=[AWL=0.029, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tls@ietf.org, Nicolas Williams X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > > What I meant (and forgot to add) was "certificate-based credential > (self-signed when no PKI is used) as a mandatory to implement > feature for interoperability". > > If support of cert-based credentials is a mere MAY, then I am sure > there will be servers/services where installing or using a PKI > credential is impossible/defective/unusable, and you cannot complain > to the vendor because not-supporting it is fully compliant with the spec. > > Everyone will be happy when Kerberos can be used cross-organization > one day. But until that day, I want to make sure that the customer > has the working alternative to use PKI when there is a need for it. > > Its important to remember that _both_ PKI and Kerberos have cross-realm issues. The main difference is that many PKI implementations allow the users to disregard the lack of cross-realm trust (eg a pre-configured trust-anchor). I know this point has been made before on this thread but I felt it was important enough to emphasize one more time. The fact that PKI implementations delegate the trust- decision to the user at session-establishment-time is arguably a source of many egregious problems. This is my way of saying that I agree with Nico that any arguments based on the fact that Kerberos doesn't have widely deployed cross-realm are just as pointless as arguments against PKI because there is no common trust-root: building federations is a hard problem and not because we haven't gotten the bits right. I do believe it is a requirement of any solution in this space that it be able to gracefully handle the case when the gss handshake fails (for whatever reason) by falling back to . I think the text used to describe this in the draft can be improved and I will try to help by offering constructive comments later on. Cheers Leif _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 20 18:25:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0uJ-0008WR-53; Fri, 20 Jul 2007 18:25:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0uH-0008WL-Jy for tls@ietf.org; Fri, 20 Jul 2007 18:25:05 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IC0uG-0001CZ-VA for tls@ietf.org; Fri, 20 Jul 2007 18:25:05 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id AAA02153; Sat, 21 Jul 2007 00:25:01 +0200 (MESZ) From: Martin Rex Message-Id: <200707202225.l6KMP1ow027548@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for To: leifj@it.su.se (Leif Johansson) Date: Sat, 21 Jul 2007 00:25:01 +0200 (MEST) In-Reply-To: <46A12124.4020000@it.su.se> from "Leif Johansson" at Jul 20, 7 10:55:00 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Nicolas.Williams@sun.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Leif Johansson wrote: > Martin Rex wrote: > > > > What I meant (and forgot to add) was "certificate-based credential > > (self-signed when no PKI is used) as a mandatory to implement > > feature for interoperability". > > > > If support of cert-based credentials is a mere MAY, then I am sure > > there will be servers/services where installing or using a PKI > > credential is impossible/defective/unusable, and you cannot complain > > to the vendor because not-supporting it is fully compliant with the spec. > > > > Everyone will be happy when Kerberos can be used cross-organization > > one day. But until that day, I want to make sure that the customer > > has the working alternative to use PKI when there is a need for it. > > > > > Its important to remember that _both_ PKI and Kerberos > have cross-realm issues. The main difference is that many > PKI implementations allow the users to disregard the lack > of cross-realm trust (eg a pre-configured trust-anchor). I beg to differ. Several PKI toothing problem can be entirely avoided by applications when the ACLs account for both, subject AND issuer of a certificate in order to support authentication from different independent PKIs. SSL/TLS Client certificates from seperate independet PKIs is fairly commen, the Web Browsers implement it and client components in distributed application backends normally also support it today. A Kerberized server that authenticates users from realms with not trust relationship is somewhere between difficult (MIT Kerberos) to impossible (Microsoft Kerberos) At least there appear to be workable approaches to deal with seperate Kerberos client credentials for independent realms (probably because it is so difficult to solve the issue on the server end). > > This is my way of saying that I agree with Nico that any > arguments based on the fact that Kerberos doesn't have > widely deployed cross-realm are just as pointless as > arguments against PKI because there is no common > trust-root: building federations is a hard problem and > not because we haven't gotten the bits right. I belief that a common trust-root is a stupid and flawed approach. Of course, the PKI guys desperately need it, because without it all their policy and name constraints stuff remains the useless bloat that it is. The Kerberos cross-organization problem exists because of the security problems and administrative problems of a cross-realm trust. A common trust-root and relying on policy&name constraints to work puts PKI technology into a similarily miserable position as Kerberos so it is really stupid to go down this road. Why do I need a dozen different plastic cards in my wallet? Can't those issuer not simply agree on a single one? Well, those issuers want to keep full authority over this card and not have to ask or negotiate with others what they may and may not do with a card. Think of revocation policies. Right now, each issue can seperately decide when to renew or revoke their card and for which reasons, and lots of other policies. If you only had one card, the rules would have to be very different (and organization would have to revoke privileges instead of revoking your credential). PKI is no silver bullet. And if you want to make best use of the existing installed-base technology today, you should probably forget about common trust-root for online authentication. > > I do believe it is a requirement of any solution in this space > that it be able to gracefully handle the case when the gss > handshake fails (for whatever reason) by falling back to > . I think the text used to describe this in the > draft can be improved and I will try to help by offering > constructive comments later on. I'm less enthusiastic about the aggressiveness of the fallback. I hate (hiden) fail-overs, because they're often the root of mysterious and hard to diagnose problems. *I* strongly prefer an initial negotation that provides a high probabilty that a particular method will succeed, and then exactly one attempt, an error message when it fails and NO (automatic) fallback. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 21 00:07:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC6FP-0006Sn-5m; Sat, 21 Jul 2007 00:07:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC6FO-0006Sh-CC for tls@ietf.org; Sat, 21 Jul 2007 00:07:14 -0400 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IC6FI-0007nG-Oy for tls@ietf.org; Sat, 21 Jul 2007 00:07:14 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6L478s3003208 for ; Sat, 21 Jul 2007 04:07:08 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6L477US001339 for ; Fri, 20 Jul 2007 22:07:07 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6L477Eg027215; Fri, 20 Jul 2007 23:07:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6L476RC027214; Fri, 20 Jul 2007 23:07:06 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 20 Jul 2007 23:07:06 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for Message-ID: <20070721040705.GO26603@Sun.COM> References: <46A12124.4020000@it.su.se> <200707202225.l6KMP1ow027548@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707202225.l6KMP1ow027548@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Martin, I definitely agree about islands of trust. If servers/acceptors/responders should be able to have credentials for multiple islands of trust[*] then we need to have them tell the client/initiator what "islands"[*] of authentication, and what mechanisms, they have credentials for. It may be too late to work federation negotiation into SPNEGO, but it makes plenty of sense to me that application protocols should handle federation and mechanism negotiation rather than pseudo-mechanisms. Here's our chance to get that right for TLS. * "worlds" or "federations" or whatever we should call it; in the Liberty, OpenID and other such communities the term used is 'federation;, so I propose we use that. Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 21 08:23:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICDz9-0003xX-GW; Sat, 21 Jul 2007 08:22:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICDz8-0003xP-Ad for tls@ietf.org; Sat, 21 Jul 2007 08:22:58 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICDz6-0007Gd-O9 for tls@ietf.org; Sat, 21 Jul 2007 08:22:58 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 8C3773BEB8; Sat, 21 Jul 2007 14:22:55 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30624-02-14; Sat, 21 Jul 2007 14:22:55 +0200 (CEST) Received: from [83.178.5.157] (m83-178-5-157.cust.tele2.se [83.178.5.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 34B0B3BEF2; Sat, 21 Jul 2007 14:22:46 +0200 (CEST) Message-ID: <46A1FA92.4040200@it.su.se> Date: Sat, 21 Jul 2007 14:22:42 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: martin.rex@sap.com Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for References: <200707202225.l6KMP1ow027548@fs4113.wdf.sap.corp> In-Reply-To: <200707202225.l6KMP1ow027548@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.06 tagged_above=-99 required=7 tests=[AWL=0.252, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tls@ietf.org, Nicolas.Williams@sun.com X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org > > I beg to differ. Several PKI toothing problem can be > entirely avoided by applications when the ACLs account > for both, subject AND issuer of a certificate in order > to support authentication from different independent PKIs. > > Then you can just aswell avoid the use of issuers at all and keep track of (say) certificate fingerprints for self-signed certs. > SSL/TLS Client certificates from seperate independet PKIs > is fairly commen, the Web Browsers implement it and > client components in distributed application backends > normally also support it today. > Which was precisely my argument. A set of roots in a common trust-store effectively makes them all equivalent in terms of trust and if you think this doesn't matter I invite you to investigate the pretty large differences that exist between the CAs that are all part of (say) the IE default trust-store. > > > > I belief that a common trust-root is a stupid and flawed approach. > Of course, the PKI guys desperately need it, because without it > all their policy and name constraints stuff remains the > useless bloat that it is. > Good, then we agree on this. > The Kerberos cross-organization problem exists because > of the security problems and administrative problems > of a cross-realm trust. > > Which are more or less exactly the same problems that exist whenever you try to setup any kind of federation. In fact most cross-realm kerberos trusts are much easier to setup and maintain than your (not so common) bridge CA. You are comparing apples and pears in this email by holding up browser-based PKI as an example of how easy cross- domain trust is compared to kerberos. In fact there are extremely few examples of cross-domain trusts (brigde-CAs) in the PKI world compared to the relatively large number of cross-realm trusts operational today. > A common trust-root and relying on policy&name constraints > to work puts PKI technology into a similarily miserable position > as Kerberos so it is really stupid to go down this road. > > Why do I need a dozen different plastic cards in my wallet? > Can't those issuer not simply agree on a single one? > In fact I sure hope not but that is definitely off topic. > > > > *I* strongly prefer an initial negotation that provides a high > probabilty that a particular method will succeed, and then > exactly one attempt, an error message when it fails and > NO (automatic) fallback. > > > -Martin > Good - this seems like the core of the disagreement. Cheers Leif _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 21 15:58:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICL5X-0006sV-1u; Sat, 21 Jul 2007 15:58:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICL5V-0006gE-5C for tls@ietf.org; Sat, 21 Jul 2007 15:58:01 -0400 Received: from [130.129.19.183] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICL5U-0007Dc-PD for tls@ietf.org; Sat, 21 Jul 2007 15:58:01 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 2AEF933C4D; Sat, 21 Jul 2007 12:46:58 -0700 (PDT) Date: Sat, 21 Jul 2007 07:05:36 -0700 From: Eric Rescorla To: Subject: Re: [TLS] Signature Hash Agility In-Reply-To: References: <20070629160611.750F933C1A@delta.rtfm.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: <20070721194658.2AEF933C4D@delta.rtfm.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org At Thu, 19 Jul 2007 15:22:56 +0300, wrote: > > Eric Rescorla wrote: > > > 3. Communicating the signature/hash algorithm you're using So, I > > agree that trying to figure out the hash from the signature > > algorithm in the cert was a mistake. We clearly need to explicitly > > name the digest algorithm in the message. However, previewing point > > (4), DSA keys need to be bound to one specific digest algorithm. > > Accordingly I think the right structure is: > > > > > struct { > > select (SignatureAlgorithm) { > > case anonymous: struct { }; > > case rsa: > > HashType digestAlgorithm; // NEW > > digitally-signed struct { > > opaque hash[Hash.length]; > > }; > > case dsa: > > digitally-signed struct { > > opaque sha_hash[20]; > > }; > > }; > > }; > > } Signature; > > > > > > And note that we'll need DigestInfo encoding to protect against hash > > substitution. > > I'd prefer a more uniform approach: > > struct { > opaque signature_algorithm<0..2^16-1>; > opaque signature_value<0..2^16-1>; > } Signature; > > where signature_algorithm is DER-encoded AlgorithmIdentifier > structure, and signature_value is the actual signature value > (and for anonymous, both are just zero-length strings). > > This would work even in the case of ANSI X9.62 encoded ECDSA > public keys, where SPKI can list more than one acceptable hash > algorithm. (If they're all secure, substitution may not be > a problem; IMHO this is a CA policy issue, and we shouldn't > hardcode this in TLS.) I'm OK with a uniform type, but I think a HashType is what's appropriate here. OIDs don't seem like the TLS way... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jul 22 12:45:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICeYP-00035n-Uo; Sun, 22 Jul 2007 12:45:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICeYO-00035i-A3 for tls@ietf.org; Sun, 22 Jul 2007 12:45:08 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICeYN-0005Yy-Ol for tls@ietf.org; Sun, 22 Jul 2007 12:45:08 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6MGiwhu010662; Sun, 22 Jul 2007 19:45:05 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 19:44:59 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 19:44:59 +0300 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 Subject: RE: [TLS] Signature Hash Agility Date: Sun, 22 Jul 2007 19:44:57 +0300 Message-ID: In-Reply-To: <20070721194658.2AEF933C4D@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Signature Hash Agility Thread-Index: AcfL0XyPrZ1Wjb9zSVShppRCJZ3+ggArW7Cg References: <20070629160611.750F933C1A@delta.rtfm.com> <20070721194658.2AEF933C4D@delta.rtfm.com> From: To: X-OriginalArrivalTime: 22 Jul 2007 16:44:59.0484 (UTC) FILETIME=[A46C91C0:01C7CC7F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > > I'd prefer a more uniform approach: > >=20 > > struct { > > opaque signature_algorithm<0..2^16-1>; > > opaque signature_value<0..2^16-1>; > > } Signature; > >=20 > > where signature_algorithm is DER-encoded AlgorithmIdentifier > > structure, and signature_value is the actual signature value=20 > > (and for anonymous, both are just zero-length strings). > >=20 > > This would work even in the case of ANSI X9.62 encoded ECDSA=20 > > public keys, where SPKI can list more than one acceptable hash=20 > > algorithm. (If they're all secure, substitution may not be=20 > > a problem; IMHO this is a CA policy issue, and we shouldn't > > hardcode this in TLS.) >=20 > I'm OK with a uniform type, but I think a HashType is what's > appropriate here. OIDs don't seem like the TLS way... I agree that OIDs are not really the TLS way... but=20 AlgorithmIdentifier would also work for signature schemes (such=20 as RSA PSS and randomized hashing) where the hash isn't the only=20 parameter needed to verify the signature. (And actual implementations for e.g. RSASSA-PKCS1-v1_5 wouldn't really need any ASN.1/DER code, just hardcoded octet string.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 23 13:10:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1Qk-0001x7-4G; Mon, 23 Jul 2007 13:10:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1Qi-0001x1-KZ for tls@lists.ietf.org; Mon, 23 Jul 2007 13:10:44 -0400 Received: from mailrelay.tu-graz.ac.at ([129.27.2.202] helo=mailrelay.tugraz.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID1Qg-0003zf-Vw for tls@lists.ietf.org; Mon, 23 Jul 2007 13:10:44 -0400 Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay1.tugraz.at (8.14.1/8.14.1) with ESMTP id l6NHAbjf008712; Mon, 23 Jul 2007 19:10:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id F21F3194009; Mon, 23 Jul 2007 19:10:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at iaik.tugraz.at Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor.iaik.tugraz.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6+OQIz53w-x; Mon, 23 Jul 2007 19:10:37 +0200 (CEST) Received: from vesta (vesta.iaik.tugraz.at [129.27.152.109]) by thor.iaik.tugraz.at (Postfix) with SMTP; Mon, 23 Jul 2007 19:10:37 +0200 (CEST) Received: from localhost [127.0.0.1] by vesta (IAIK S/MIME Mapper 2.02 12 June 2002); Mo, 23 Jul 2007 19:10:12 +0100 Message-ID: <059301c7cd4c$54a66cb0$6d981b81@iaik.tugraz.at> From: "Dieter Bratko" To: "Dr Stephen Henson" References: <469B6AB7.2090202@drh-consultancy.demon.co.uk> Subject: Re: [TLS] Support for TLS extensions Date: Mon, 23 Jul 2007 19:10:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Scanner: SpamAssassin 3.002001 X-Spam-Score-relay: -2.6 X-Scanned-By: MIMEDefang 2.62 on 129.27.10.18 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@lists.ietf.org, Axel.Heider@gi-de.com X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Hello, > On a similar subject if RFC4507 could be enabled > (or if anyone knows a public server or implementation > supporting it) that would be great. The SessionTicket extension according to RFC4507 is supported by our Java SSL/TLS toolkit; also the max_fragment_length extension and all other standard extensions specified by RFC 3546 (server_name, client_certificate_url, trusted_ca_keys, truncated_hmac, status_request) . Please see http://jce.iaik.tugraz.at/sic/products/communication_messaging_security/isasilkRegards,Dieter---------Dieter Bratko, SIC/IAIK - Graz University of TechnologyInffeldgasse 16a, 8010 Graz, Austria, http://jce.iaik.tugraz.at/----- Original Message -----From: Dr Stephen HensonTo: Peter GutmannCc: RDugal@certicom.com ; tls@lists.ietf.org ; Axel.Heider@gi-de.comSent: Monday, July 16, 2007 2:55 PMSubject: Re: [TLS] Support for TLS extensionsPeter Gutmann wrote:> Rob Dugal writes:>>> We support the max_fragment_length extension in our SSL-C product. If you>> want to test interop I'll see if we can enable it on tls.secg.org>> That'd be most useful, thanks.>> (Since SECG is probably the reference location for things like the ECCsuites,> would it be possible to set up a permanent server, not necessarily themain> secg.org one, that can be kept online and used in the future for new> implementations and for regresssion testing?).>On a similar subject if RFC4507 could! be enabled (or if anyone knows apublic server or implementation supporting it) that would be great. I'dlike to perform some interop testing at some point.Steve.--Dr Stephen N. Henson.Core developer of the OpenSSL project: http://www.openssl.org/Freelance consultant see: http://www.drh-consultancy.co.uk/Email: shenson@drh-consultancy.co.uk, PGP key: via homepage._______________________________________________TLS mailing listTLS@lists.ietf.orghttps://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 23 16:35:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4d2-0000ZG-Aw; Mon, 23 Jul 2007 16:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4d0-0000Wv-A8 for tls@lists.ietf.org; Mon, 23 Jul 2007 16:35:38 -0400 Received: from relay2.mail.uk.clara.net ([80.168.70.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID4cy-00030L-Rf for tls@lists.ietf.org; Mon, 23 Jul 2007 16:35:38 -0400 Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.10]) by relay2.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from ) id 1ID4cw-0006JP-FV; Mon, 23 Jul 2007 21:35:36 +0100 Message-ID: <46A51101.9020702@drh-consultancy.demon.co.uk> Date: Mon, 23 Jul 2007 21:35:13 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Dieter Bratko Subject: Re: [TLS] Support for TLS extensions References: <469B6AB7.2090202@drh-consultancy.demon.co.uk> <059301c7cd4c$54a66cb0$6d981b81@iaik.tugraz.at> In-Reply-To: <059301c7cd4c$54a66cb0$6d981b81@iaik.tugraz.at> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Dieter Bratko wrote: > Hello, > >> On a similar subject if RFC4507 could be enabled >> (or if anyone knows a public server or implementation >> supporting it) that would be great. > > The SessionTicket extension according to RFC4507 is > supported by our Java SSL/TLS toolkit; also the > max_fragment_length extension and all other standard > extensions specified by RFC 3546 (server_name, > client_certificate_url, trusted_ca_keys, truncated_hmac, > status_request) . Please see > http://jce.iaik.tugraz.at/sic/products/communication_messaging_security/isasilk Thank you for the pointer. The demo server at: http://jce.iaik.tugraz.at/sic/products/communication_messaging_security/isasilk/demo doesn't seem to be working at present. Do any of your public SSL servers support RFC4507 or do you have a demo server that could be used for interop testing? I tested www.iaik.at but it didn't respond with any TLS extensions. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 24 04:48:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDG3c-0001ZM-H9; Tue, 24 Jul 2007 04:47:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDG3Y-0001Yw-PQ for tls@lists.ietf.org; Tue, 24 Jul 2007 04:47:50 -0400 Received: from mailrelay.tu-graz.ac.at ([129.27.2.202] helo=mailrelay.tugraz.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDG3X-0000kU-4w for tls@lists.ietf.org; Tue, 24 Jul 2007 04:47:48 -0400 Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay2.tugraz.at (8.14.1/8.14.1) with ESMTP id l6O8lfeu000071; Tue, 24 Jul 2007 10:47:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 84D9219C001; Tue, 24 Jul 2007 10:47:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at iaik.tugraz.at Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor.iaik.tugraz.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyRPmYF0FXMK; Tue, 24 Jul 2007 10:47:41 +0200 (CEST) Received: from vesta (vesta.iaik.tugraz.at [129.27.152.109]) by thor.iaik.tugraz.at (Postfix) with SMTP; Tue, 24 Jul 2007 10:47:41 +0200 (CEST) Message-ID: <00a701c7cdcf$4b5a9360$6d981b81@iaik.tugraz.at> From: "Dieter Bratko" To: "Dr Stephen Henson" References: <469B6AB7.2090202@drh-consultancy.demon.co.uk> <059301c7cd4c$54a66cb0$6d981b81@iaik.tugraz.at> <46A51101.9020702@drh-consultancy.demon.co.uk> Subject: Re: [TLS] Support for TLS extensions Date: Tue, 24 Jul 2007 10:47:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Scanner: SpamAssassin 3.002001 X-Spam-Score-relay: -2.6 X-Scanned-By: MIMEDefang 2.62 on 129.27.10.19 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Hello Steve, > Thank you for the pointer. The demo server at: > > http://jce.iaik.tugraz.at/sic/products/communication_messaging_security/isasilk/demo > > doesn't seem to be working at present. Thanks for the note; we are setting up a new server, > Do any of your public SSL servers support RFC4507 or do you have a demo > server that could be used for interop testing? You may download the iSaSiLk toolkit; it contains batch and shell scripts (cmd/extensions, sh/extensions) for running small demo servers and clients that can be used for testing. The demo sources are included and can be easily modified to changes the properties if required. Regards, Dieter ----- Original Message ----- From: Dr Stephen Henson To: Dieter Bratko Cc: tls@lists.ietf.org Sent: Monday, July 23, 2007 10:35 PM Subject: Re: [TLS] Support for TLS extensions Dieter Bratko wrote: > Hello, > >> On a similar subject if RFC4507 could be enabled >> (or if anyone knows a public server or implementation >> supporting it) that would be great. > > The SessionTicket extension according to RFC4507 is > supported by our Java SSL/TLS toolkit; also the > max_fragment_length extension and all other standard > extensions specified by RFC 3546 (server_name, > client_certificate_url, trusted_ca_keys, truncated_hmac, > status_request) . Please see > http://jce.iaik.tugraz.at/sic/products/communication_messaging_security/isasilk Thank you for the pointer. The demo server at: http://jce.iaik.tugraz.at/sic/products/communication_messaging_security/isasilk/demo doesn't seem to be working at present. Do any of your public SSL servers support RFC4507 or do you have a demo server that could be used for interop testing? I tested www.iaik.at but it didn't respond with any TLS extensions. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 24 10:44:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLcx-0004n3-2M; Tue, 24 Jul 2007 10:44:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLcv-0004mv-Rd for tls@lists.ietf.org; Tue, 24 Jul 2007 10:44:41 -0400 Received: from web37015.mail.mud.yahoo.com ([209.191.85.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IDLcv-0000M3-DY for tls@lists.ietf.org; Tue, 24 Jul 2007 10:44:41 -0400 Received: (qmail 65884 invoked by uid 60001); 24 Jul 2007 14:44:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=1PnHkL6v+Ux72TH0vN+PwUJduvZka9U9k7VptMgwb9/m/fvOMq0hXWz7XsiIsNQAGZhh7HWI9glJ33XdA7SIhWIqGXzwwih4bnFacIZwdH9FnEV5oWT4Bjx2xEtSea6+LYOrATw0dnjEFsVrNMaZ6F2Z+N5/J65XrQ8HQS8RKAE=; X-YMail-OSG: ymNm9VYVM1kVEAFdCEeqQbTU2TNflKRBXIkKeseN3tarO9YK1cQIAo1eL3oiHHMWyABQFZ5Jwg-- Received: from [12.27.4.50] by web37015.mail.mud.yahoo.com via HTTP; Tue, 24 Jul 2007 07:44:40 PDT Date: Tue, 24 Jul 2007 07:44:40 -0700 (PDT) From: Ken Peirce To: tls@lists.ietf.org MIME-Version: 1.0 Message-ID: <995709.65193.qm@web37015.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [TLS] opensource implementations of TLS-SRP? X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============1733279131==" Errors-To: tls-bounces@lists.ietf.org --===============1733279131== Content-Type: multipart/alternative; boundary="0-1802658672-1185288280=:65193" Content-Transfer-Encoding: 8bit --0-1802658672-1185288280=:65193 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Does anyone know of an opensource TLS SRP implementation? Cheers, Ken Peirce --0-1802658672-1185288280=:65193 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Does anyone know of an opensource TLS SRP implementation?
Cheers,
Ken Peirce

--0-1802658672-1185288280=:65193-- --===============1733279131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1733279131==-- From tls-bounces@lists.ietf.org Tue Jul 24 11:24:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMFf-0000Yr-Hw; Tue, 24 Jul 2007 11:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMFe-0000Yg-Rs for tls@ietf.org; Tue, 24 Jul 2007 11:24:42 -0400 Received: from mail.opera.com ([213.236.208.66] helo=mailbox.opera.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDMFd-0001oY-7U for tls@ietf.org; Tue, 24 Jul 2007 11:24:42 -0400 Received: from killashandra-ii.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) by mailbox.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l6OFOVrg028185; Tue, 24 Jul 2007 15:24:35 GMT Date: Tue, 24 Jul 2007 17:25:00 +0200 To: "Eric Rescorla" , tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-rfc4346-04 available From: "Yngve Nysaeter Pettersen" Organization: Opera Software Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20070708145051.4C2B033C55@delta.rtfm.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20070708145051.4C2B033C55@delta.rtfm.com> User-Agent: Opera Mail/9.21 (Win32) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yngve@opera.com 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: , Errors-To: tls-bounces@lists.ietf.org On Sun, 08 Jul 2007 16:50:51 +0200, Eric Rescorla wrote: > I just submitted draft-ietf-tls-rfc4346-04. > > Until it's in the repository, you can find it at: > https://svn.resiprocate.org/rep/ietf-drafts/ekr/tls/tls.txt > > The changes are: > > - Added some guidance about checking DH groups and exponents. > [Issues 15 and 43] I think this: "The client SHOULD also verify that the DH public exponent appears to be of adequate size." ought to be worded stronger, perhaps something like "The client SHOULD also verify that the DH public exponent is of equvalent cryptograhic strength as the key used to sign the public key." (Yesterday there were two reports to Opera about such weak keys at Hushmail) This might also be phrased in a way that allows it to apply to other temporary key methods, as well. Perhaps there should be some advice on what a client should do in case the key is considered too weak? My suggestion would be that the client should renogiate with the ephemeral ciphersuites less preferred than non-ephemeral ciphersuites. The drawback is that this will make the negotiation process more complicated. Another possibility would be to send the insufficient_security alert as a warning (which would require redefining the alert) even if the connection is accepted. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 24 12:30:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNHf-00054M-Ec; Tue, 24 Jul 2007 12:30:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNHd-000540-Md for tls@ietf.org; Tue, 24 Jul 2007 12:30:49 -0400 Received: from dhcp-11b6.ietf69.org ([130.129.17.182] helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDNHd-0007xf-AK for tls@ietf.org; Tue, 24 Jul 2007 12:30:49 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 35D0833C39; Tue, 24 Jul 2007 09:28:42 -0700 (PDT) Date: Tue, 24 Jul 2007 09:28:41 -0700 From: Eric Rescorla To: yngve@opera.com Subject: Re: [TLS] draft-ietf-tls-rfc4346-04 available In-Reply-To: References: <20070708145051.4C2B033C55@delta.rtfm.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: <20070724162842.35D0833C39@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org At Tue, 24 Jul 2007 17:25:00 +0200, Yngve Nysaeter Pettersen wrote: > > On Sun, 08 Jul 2007 16:50:51 +0200, Eric Rescorla > wrote: > > > I just submitted draft-ietf-tls-rfc4346-04. > > > > Until it's in the repository, you can find it at: > > https://svn.resiprocate.org/rep/ietf-drafts/ekr/tls/tls.txt > > > > The changes are: > > > > - Added some guidance about checking DH groups and exponents. > > [Issues 15 and 43] > > I think this: > > "The client SHOULD also verify that the DH public exponent appears to be > of adequate size." > > ought to be worded stronger, perhaps something like > > "The client SHOULD also verify that the DH public exponent is of > equvalent cryptograhic strength as the key used to sign the public key." I actually do not agree with this position. There are valid reasons to use long signing keys and shorter key establishment keys. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 24 13:36:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOJ8-0000BQ-Nu; Tue, 24 Jul 2007 13:36:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOJ6-0000BA-Db for tls@ietf.org; Tue, 24 Jul 2007 13:36:24 -0400 Received: from sam.opera.com ([213.236.208.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDOJ5-0001q1-Lo for tls@ietf.org; Tue, 24 Jul 2007 13:36:24 -0400 Received: from lessa-ii (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by sam.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l6OHaC45001879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Jul 2007 17:36:15 GMT Date: Tue, 24 Jul 2007 19:36:18 +0200 To: "Eric Rescorla" Subject: Re: [TLS] draft-ietf-tls-rfc4346-04 available From: "Yngve N. Pettersen" Organization: Opera Software ASA Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20070708145051.4C2B033C55@delta.rtfm.com> <20070724162842.35D0833C39@delta.rtfm.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20070724162842.35D0833C39@delta.rtfm.com> User-Agent: Opera Mail/9.22 (Win32) X-Virus-Scanned: ClamAV 0.90.1/3754/Tue Jul 24 13:41:21 2007 on sam.opera.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Tue, 24 Jul 2007 18:28:41 +0200, Eric Rescorla wrote: > At Tue, 24 Jul 2007 17:25:00 +0200, > Yngve Nysaeter Pettersen wrote: >> I think this: >> >> "The client SHOULD also verify that the DH public exponent appears to >> be >> of adequate size." >> >> ought to be worded stronger, perhaps something like >> >> "The client SHOULD also verify that the DH public exponent is of >> equvalent cryptograhic strength as the key used to sign the public key." > > I actually do not agree with this position. There are valid reasons > to use long signing keys and shorter key establishment keys. Maybe. Alternatively, I'd like some guidance about how to determine what "adequate size" is. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 24 13:38:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOL8-0000Ub-EW; Tue, 24 Jul 2007 13:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOL7-0000UN-4Q for tls@lists.ietf.org; Tue, 24 Jul 2007 13:38:29 -0400 Received: from mail12.simplicato.com ([207.99.47.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDOL6-0006oF-Mq for tls@lists.ietf.org; Tue, 24 Jul 2007 13:38:29 -0400 Received: from mail12.simplicato.com (localhost [207.99.47.64]) by mail12.simplicato.com (Postfix) with ESMTP id 7DA91E68A; Tue, 24 Jul 2007 13:38:28 -0400 (EDT) Received: from btrev.cryptography.com (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail12.simplicato.com (Postfix) with ESMTP id 03C73E63C; Tue, 24 Jul 2007 13:38:27 -0400 (EDT) Message-ID: <46A638E1.5040800@trevp.net> Date: Tue, 24 Jul 2007 10:37:37 -0700 From: Trevor Perrin User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Ken Peirce Subject: Re: [TLS] opensource implementations of TLS-SRP? References: <995709.65193.qm@web37015.mail.mud.yahoo.com> In-Reply-To: <995709.65193.qm@web37015.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Ken Peirce wrote: > Does anyone know of an opensource TLS SRP implementation? Yes, but they will need to be updated once the RFC issues, since assigned numbers will change. - http://www.edelweb.fr/EdelKey/ (OpenSSL, C-based) - http://www.trevp.net/tlslite/ (Python-based) - http://www.gnu.org/software/gnutls/ (C-based, GPL) (see recent list archives for more detail) Trevor _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 25 13:50:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDl0E-00031X-RQ; Wed, 25 Jul 2007 13:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDl0D-00031S-Uq for tls@ietf.org; Wed, 25 Jul 2007 13:50:25 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDl0C-0007qW-4N for tls@ietf.org; Wed, 25 Jul 2007 13:50:25 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6PHoHVi011056 for ; Wed, 25 Jul 2007 20:50:22 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 20:50:21 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 20:50:20 +0300 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: Wed, 25 Jul 2007 20:50:17 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 26: implementation pitfalls Thread-Index: AcfO5EK6dzw7KcZ0TXSwPp72IrYQVg== From: To: X-OriginalArrivalTime: 25 Jul 2007 17:50:20.0911 (UTC) FILETIME=[450417F0:01C7CEE4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Subject: [TLS] Issue 26: implementation pitfalls X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I promised to write a first draft for a "implementation pitfalls" appendix; comments are welcome. Best regards, Pasi D.4 Implementation Pitfalls Implementation experience has shown that certain parts of earlier TLS specifications are not easy to understand, and have been a source of interoperability and security problems. Many of these areas have been clarified in this document, but this appendix contains a short list of the most important things that require special attention from implementors. TLS protocol issues: o Do you correctly handle handshake messages that are fragmented to multiple TLS records (see Section 6.2.1)? Including corner cases like a ClientHello that is split to several small fragments? o Do you ignore the TLS record layer version number in all TLS records before ServerHello (see Appendix E.1)? o Do you handle TLS extensions in ClientHello correctly, including omitting the extensions field completely? o Do you support renegotiation, both client and server initiated? While While renegotiation this is an optional feature, supporting renegotit is highly recommended. Cryptographic details: o In RSA-encrypted Premaster Secret, do you correctly send and=20 verify the version number? When an error is encountered, do=20 you continue the handshake to avoid the Bleichenbacher=20 attack (see Section 7.4.7.1)? o What countermeasures do you use to prevent timing attacks against RSA decryption and signing operations (see Section 7.4.7.1)? o When verifying RSA signatures, do you accept both NULL and missing parameters (see Section 4.7)? Do you verify that the RSA padding doesn't have additional data after the hash value? [FI06] o When using Diffie-Hellman key exchange, do you correctly strip leading zero bytes from the negotiated key (see Section 8.1.2)?=20 o Does your TLS client check that the Diffie-Hellman parameters=20 sent by the server are acceptable (see Section F.1.1.3)? o How do you generate unpredictable IVs for CBC mode ciphers (see Section 6.2.3.2)?=20 o How do you address CBC mode timing attacks (Section 6.2.3.2)? o Do you use a strong and, most importantly, properly seeded random number generator (see Appendix D.1) for generating the premaster secret (for RSA key exchange), Diffie-Hellman private values, the DSA "k" parameter, and other security-critical values? (and add to references) [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on implementation error", ietf-openpgp@imc.org mailing list, 27 August 2006, http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html. (end) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 25 14:18:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlRf-0001HT-Ff; Wed, 25 Jul 2007 14:18:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlRd-0001En-4I for tls@ietf.org; Wed, 25 Jul 2007 14:18:45 -0400 Received: from relay4.mail.uk.clara.net ([80.168.70.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDlRc-0005Eo-H5 for tls@ietf.org; Wed, 25 Jul 2007 14:18:45 -0400 Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.10]) by relay4.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from ) id 1IDlRU-0004Sw-60; Wed, 25 Jul 2007 19:18:38 +0100 Message-ID: <46A793E8.8080906@drh-consultancy.demon.co.uk> Date: Wed, 25 Jul 2007 19:18:16 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Issue 26: implementation pitfalls References: In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com wrote: > > o When verifying RSA signatures, do you accept both NULL and > missing parameters (see Section 4.7)? Do you verify that the > RSA padding doesn't have additional data after the hash value? > [FI06] > A variation on the attack is to include additional data in the middle of the structure for example via a parameter. That might be covered by saying NULL and missing parameters *only* though a decoder that accepted invalid content octets in a NULL value would still be vulnerable. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 25 15:24:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDmSe-000845-D9; Wed, 25 Jul 2007 15:23:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDmSd-000833-Fr for tls@ietf.org; Wed, 25 Jul 2007 15:23:51 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDmSc-0002PG-SO for tls@ietf.org; Wed, 25 Jul 2007 15:23:51 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6PJNo0c008508 for ; Wed, 25 Jul 2007 19:23:50 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLR003011NR3Z00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for tls@ietf.org; Wed, 25 Jul 2007 13:23:50 -0600 (MDT) Received: from [10.1.110.5] (dhcp-26f9.ietf69.org [130.129.38.249]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLR00JJZ1VNGA10@mail-amer.sun.com>; Wed, 25 Jul 2007 13:23:50 -0600 (MDT) Date: Wed, 25 Jul 2007 14:24:31 -0500 From: Chris Newman Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating In-reply-to: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> To: martin.rex@sap.com, Larry Zhu Message-id: <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org For my IESG review of draft-ietf-tls-srp-14.txt, I voted to abstain with the following comment: ------ This a matter of application software architecture that applies to any user-based authentication mechanism embedded in TLS that involves or may involve unspecified server storage of per-user credential information. TLS stacks and the APIs to TLS stacks have started to ossify into operating systems, mobile devices and shipping application software. Such stacks are absolutely critical to application security, and are already so complex that they are the cause of a significant number of software defects and security updates. I am very concerned about adding unnecessary complexity to such a critical software component. There is already a great deal of flux upgrading the cipher suites, cipher modes and hash functions in these stacks. Meanwhile, all the software infrastructure in applications surrounding user identity, server credential repositories for users, and identity federation is highly complex and in a great deal of flux. If one looks at the amount of complexity in the GSSAPI or deployed general purpose SASL APIs and imagines the complexity of a software stack including all those APIs blended with a TLS API, I find the prospect daunting. Indeed the complexity is sufficiently great that I consider it bad architecture. Meanwhile, there's a viable alternative. If TLS and an authentication framework such as GSSAPI, EAP or SASL are loosely bound using a mechanism such as TLS channel bindings (TLS negotiates the security layer which is subsequently bound to a completely separate user authentication), then there is a very simple and clean boundary between the two software stacks, leading to a much more pragmatic real-world architecture. ------ I have subsequently spoken to other implementers in the applications area who integrate TLS and identity stacks into their application server software. They all shared this concern to varying degrees. This issue clearly also applies to a mechanism that embeds GSS in TLS. As a measure of IETF consensus in support of such a mechanism, I want to see evidence there are real-world consumers of this technology sufficient that it might deploy. Specifically, is this likely to be implemented in multiple TLS stacks? Are applications that consume TLS stacks interested in using this instead of their present identity APIs and models? - Chris Newman Applications Area Director _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 25 15:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDmrF-0006tI-Az; Wed, 25 Jul 2007 15:49:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDmrE-0006tD-9q for tls@ietf.org; Wed, 25 Jul 2007 15:49:16 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDmrD-0007qa-J7 for tls@ietf.org; Wed, 25 Jul 2007 15:49:16 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Wed, 25 Jul 2007 12:49:14 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.726.0; Wed, 25 Jul 2007 12:49:14 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jul 2007 12:49:14 -0700 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 Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating Date: Wed, 25 Jul 2007 12:48:21 -0700 Message-ID: In-Reply-To: <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] the use cases for GSS-based TLS and the plea for integrating Thread-Index: AcfO8VlgSP6s2gjwQV+P/Szohn+fswAAFr7Q References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> From: Larry Zhu To: , X-OriginalArrivalTime: 25 Jul 2007 19:49:14.0211 (UTC) FILETIME=[E0CB4B30:01C7CEF4] X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org For use cases, please review my slides and the meeting minutes for the TLS working group. I would like to recap the main points below: Methodology wise the way to deal with complexity is to build abstraction layers. GSS-API is ideal for encapsulating the described complexity.=20 We strongly believe there is a confusing message in IETF. Our security AD made a presentation in the TLS working group yesterday and the message is that we want everyone to use TLS for everything. But you can't use Kerberos in TLS in a secure fashion today. The FXA-TLS fills in this gap. It is not a conspiracy that the two presentations were arranged together with my slides extending Tim's slides in that sense. With FXA-TLS, one can use both certificate based authentication and Kerberos using one mechanism. No one wants to design their protocols once with Kerberos and once with TLS, no one want to review their protocols twice. Experience has clearly shown that requiring two set of mechanisms (one for Kerb and one for TLS) adds a lot of unnecessary complexity to what is already too complex. Not to mention the burden to test two sets of mechanisms. We the IETF really should build a better building block for future IETF standard protocols and deliver a coherent strategy/solution.=20 Non-IETF protocols that do not have a SASL variant do not even have a choice, we have to integrate Kerberos into the TLS stack to get Kerberos to work, not to mention the practical reasons due to firewalls and NAT traversal. --larry -----Original Message----- From: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM]=20 Sent: Wednesday, July 25, 2007 12:25 PM To: martin.rex@sap.com; Larry Zhu Cc: tls@ietf.org Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating For my IESG review of draft-ietf-tls-srp-14.txt, I voted to abstain with the=20 following comment: ------ This a matter of application software architecture that applies to any user-based authentication mechanism embedded in TLS that involves or may involve unspecified server storage of per-user credential information. TLS stacks and the APIs to TLS stacks have started to ossify into operating systems, mobile devices and shipping application software. Such stacks are absolutely critical to application security, and are already so complex that they are the cause of a significant number of software defects and security updates. I am very concerned about adding unnecessary complexity to such a critical software component. There is already a great deal of flux upgrading the cipher suites, cipher modes and hash functions in these stacks. Meanwhile, all the software infrastructure in applications surrounding user identity, server credential repositories for users, and identity federation is highly complex and in a great deal of flux. If one looks at the amount of complexity in the GSSAPI or deployed general purpose SASL APIs and imagines the complexity of a software stack including all those APIs blended with a TLS API, I find the prospect daunting. Indeed the complexity is sufficiently great that I consider it bad architecture. Meanwhile, there's a viable alternative. If TLS and an authentication framework such as GSSAPI, EAP or SASL are loosely bound using a mechanism such as TLS channel bindings (TLS negotiates the security layer which is subsequently bound to a completely separate user authentication), then there is a very simple and clean boundary between the two software stacks, leading to a much more pragmatic real-world architecture. ------ I have subsequently spoken to other implementers in the applications area who=20 integrate TLS and identity stacks into their application server software. They=20 all shared this concern to varying degrees. This issue clearly also applies to a mechanism that embeds GSS in TLS. As a=20 measure of IETF consensus in support of such a mechanism, I want to see=20 evidence there are real-world consumers of this technology sufficient that it=20 might deploy. Specifically, is this likely to be implemented in multiple TLS=20 stacks? Are applications that consume TLS stacks interested in using this=20 instead of their present identity APIs and models? - Chris Newman Applications Area Director _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 26 11:47:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5YW-0004I1-OQ; Thu, 26 Jul 2007 11:47:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5YU-0004Ha-R3 for tls@ietf.org; Thu, 26 Jul 2007 11:47:10 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE5YS-0001M1-Nm for tls@ietf.org; Thu, 26 Jul 2007 11:47:10 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l6QFl08W022320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 17:47:04 +0200 X-Hashcash: 1:22:070726:chris.newman@sun.com::BQrEmKZzuOWZl2m9:kyM X-Hashcash: 1:22:070726:lzhu@windows.microsoft.com::WzSY+ahOMajG3SDp:GRgp From: Simon Josefsson To: Chris Newman References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070726:martin.rex@sap.com::SBCC8jjo72G2ZejY:zYW X-Hashcash: 1:22:070726:tls@ietf.org::Enfgwagvn12ruEsY:2eDJ Date: Thu, 26 Jul 2007 17:46:58 +0200 In-Reply-To: <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> (Chris Newman's message of "Wed, 25 Jul 2007 14:24:31 -0500") Message-ID: <873azbgob1.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@ietf.org Subject: [TLS] Re: the use cases for GSS-based TLS and the plea for integrating X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Chris Newman writes: > sufficient that it might deploy. Specifically, is this likely to be > implemented in multiple TLS stacks? Are applications that consume TLS I believe GSS-API support in TLS, either directly, or through some generic external-authentication-protocol (which may use channel bindings to bind the external authentication to the TLS stream) is a good idea. We all know RFC 2712 is broken. GSSAPI-in-TLS seems like a simple way fix both RFC 2712 and enable other useful things. I've been planning to implement Kerberos/GSS-API support in GnuTLS, but until there is consensus around a specific protocol I can't start. I think it would be useful if those who are opposed to the past, and current, GSSAPI-in-TLS proposals describe how they like GSS-API to be implemented in TLS rather than criticizing the proposals. Alternatively, if they see any other non-GSS-API way to integrate Kerberos into TLS, as that appear to be the main use-case for GSSAPI-in-TLS. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 26 12:00:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5ku-0005iJ-Iz; Thu, 26 Jul 2007 12:00:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5kt-0005i6-61 for tls@ietf.org; Thu, 26 Jul 2007 11:59:59 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE5ks-0000XR-5T for tls@ietf.org; Thu, 26 Jul 2007 11:59:58 -0400 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6QFxvCs023595 for ; Thu, 26 Jul 2007 15:59:57 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLS00B01MH90O00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for tls@ietf.org; Thu, 26 Jul 2007 09:59:57 -0600 (MDT) Received: from [10.1.110.5] (dhcp-1695.ietf69.org [130.129.22.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLS005G0N3UAZ10@mail-amer.sun.com>; Thu, 26 Jul 2007 09:59:57 -0600 (MDT) Date: Thu, 26 Jul 2007 11:00:39 -0500 From: Chris Newman Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating In-reply-to: To: Larry Zhu , martin.rex@sap.com Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Larry Zhu wrote on 7/25/07 12:48 -0700: > For use cases, please review my slides and the meeting minutes for the > TLS working group. I would like to recap the main points below: I will look at them. > Methodology wise the way to deal with complexity is to build abstraction > layers. GSS-API is ideal for encapsulating the described complexity. Abstraction layers can decrease complexity, increase complexity, cause "data hiding" (good), and "data losing" (bad). How abstraction layers are hooked together matters a great deal. There's an abstraction layer between applications and TLS. There's an abstraction layer between applications and SASL/GSSAPI. But what you're proposing shoves GSSAPI behind the TLS abstraction, creating a clear case of "data losing" in the abstraction model. That would require punching holes through the TLS abstraction layer so the application can control both GSSAPI and any back channels GSSAPI uses to talk to user authentication repositories or trusted third parties. > We strongly believe there is a confusing message in IETF. Our security > AD made a presentation in the TLS working group yesterday and the > message is that we want everyone to use TLS for everything. A bit of a confused message is inevitable in a rough consensus organization. We're participating as individuals and have different perspectives and positions as individuals. The work to form a rough consensus can be messy. But I hear your complaint and will talk to Tim to see if the two of us can agree on a more unified message. For starters, I would agree that when a security services layer is needed in an application protocol stack that TLS is likely the right mechanism to provide that layer. I'm not convinced the "SL" portion of "SASL" has any value in practice. > No one wants to design their protocols > once with Kerberos and once with TLS, no one want to review their > protocols twice. Experience has clearly shown that requiring two set of > mechanisms (one for Kerb and one for TLS) adds a lot of unnecessary > complexity to what is already too complex. I'd agree that implementers only want to integrate one security services layer. But some implementers want their security services layer and identity stack to be as cleanly separated as possible so a tight binding between the two is not desirable. TLS only provides certificate-based identity today, a mechanism that is very different from other user identity services because it does not require the TLS stack to perform a user identity network lookup in the middle of the TLS handshake. Doing that means the TLS stack suddenly has to communicate problems talking to the identity lookup service through the TLS stack and back to the application. > Not to mention the burden to > test two sets of mechanisms. We the IETF really should build a better > building block for future IETF standard protocols and deliver a coherent > strategy/solution. It's more important to build a strategy/solution that can be deployed and sustained in the real world with multiple independent interoperable implementations. > Non-IETF protocols that do not have a SASL variant do not even have a > choice, we have to integrate Kerberos into the TLS stack to get Kerberos > to work, not to mention the practical reasons due to firewalls and NAT > traversal. An application protocol that needs user-level authentication and fails to include an authentication framing mechanism in the protocol is designed incorrectly, and the fact some non-IETF protocols have that problem is not a reason to add complexity to IETF protocols. HTTP has such a framing mechanism, SSH has one, also SASL, GSSAPI and EAP include protocol abstractions that could be used to provide such a mechanism in any other application protocol. If you try to solve the general application-layer user authentication problem in the TLS stack, that adds a bunch of requirements to TLS that it probably shouldn't have if there's a desire to keep the stack simple. An example would be error messages suitable for end-user consumption and the language negotiation necessary for such messages (SSH does this, for example). - Chris _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 26 12:10:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5v1-0007J6-E6; Thu, 26 Jul 2007 12:10:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5uz-0007FB-CG for tls@ietf.org; Thu, 26 Jul 2007 12:10:25 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE5ux-00022S-Tc for tls@ietf.org; Thu, 26 Jul 2007 12:10:25 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 08E4C3BF5F; Thu, 26 Jul 2007 18:10:21 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15858-02-4; Thu, 26 Jul 2007 18:10:20 +0200 (CEST) Received: from [130.129.18.102] (dhcp-1266.ietf69.org [130.129.18.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 903283BF1F; Thu, 26 Jul 2007 18:10:15 +0200 (CEST) Message-ID: <46A8C770.9030108@it.su.se> Date: Thu, 26 Jul 2007 18:10:24 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Simon Josefsson Subject: Re: [TLS] Re: the use cases for GSS-based TLS and the plea for integrating References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> <873azbgob1.fsf@mocca.josefsson.org> In-Reply-To: <873azbgob1.fsf@mocca.josefsson.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.946 tagged_above=-99 required=7 tests=[AWL=0.366, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Chris Newman , tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson wrote: > Chris Newman writes: > > >> sufficient that it might deploy. Specifically, is this likely to be >> implemented in multiple TLS stacks? Are applications that consume TLS >> > > I believe GSS-API support in TLS, either directly, or through some > generic external-authentication-protocol (which may use channel bindings > to bind the external authentication to the TLS stream) is a good idea. > We all know RFC 2712 is broken. GSSAPI-in-TLS seems like a simple way > fix both RFC 2712 and enable other useful things. > > I fully agree with this. Cheers Leif _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 26 12:32:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE6Fx-0003oj-FL; Thu, 26 Jul 2007 12:32:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE6Fv-0003k5-Ge for tls@ietf.org; Thu, 26 Jul 2007 12:32:03 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE6Fu-0003DV-0V for tls@ietf.org; Thu, 26 Jul 2007 12:32:03 -0400 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 26 Jul 2007 09:32:00 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.726.0; Thu, 26 Jul 2007 09:32:00 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jul 2007 09:31:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating Date: Thu, 26 Jul 2007 09:31:02 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] the use cases for GSS-based TLS and the plea for integrating Thread-Index: AcfPng+No1bDJ4ZNTGSDcg6wCzOHKQAA5VSs References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> From: Larry Zhu To: Chris Newman , X-OriginalArrivalTime: 26 Jul 2007 16:31:59.0907 (UTC) FILETIME=[7D698F30:01C7CFA2] X-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============1063126754==" Errors-To: tls-bounces@lists.ietf.org --===============1063126754== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CFA2.5B4CBE88" ------_=_NextPart_001_01C7CFA2.5B4CBE88 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chris Newman wrote: > TLS only provides certificate-based identity today, a mechanism=20 > that is very different from other user identity services because it = does not=20 > require the TLS stack to perform a user identity network lookup in the = middle=20 > of the TLS handshake. Doing that means the TLS stack suddenly has to=20 > communicate problems talking to the identity lookup service through = the TLS=20 > stack and back to the application. Reading what you are saying, I suspect you have somewhat misunderstood = the proposal and the GSS-API abstraction in general.=20 Unfortunately I am on my way home. Thanks for the delay in the airport I = am still phyiscally in Chicago. I would suggest for you to talk with Sam = Hartman before making further comments on the proposal or GSS-API. thanks, --larry -----Original Message----- From: Chris Newman [mailto:Chris.Newman@Sun.COM] Sent: Thu 7/26/2007 9:00 AM To: Larry Zhu; martin.rex@sap.com Cc: tls@ietf.org Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for = integrating =20 Larry Zhu wrote on 7/25/07 12:48 -0700: > For use cases, please review my slides and the meeting minutes for the > TLS working group. I would like to recap the main points below: I will look at them. > Methodology wise the way to deal with complexity is to build = abstraction > layers. GSS-API is ideal for encapsulating the described complexity. Abstraction layers can decrease complexity, increase complexity, cause = "data=20 hiding" (good), and "data losing" (bad). How abstraction layers are = hooked=20 together matters a great deal. There's an abstraction layer between=20 applications and TLS. There's an abstraction layer between applications = and=20 SASL/GSSAPI. But what you're proposing shoves GSSAPI behind the TLS=20 abstraction, creating a clear case of "data losing" in the abstraction = model.=20 That would require punching holes through the TLS abstraction layer so = the=20 application can control both GSSAPI and any back channels GSSAPI uses to = talk=20 to user authentication repositories or trusted third parties. > We strongly believe there is a confusing message in IETF. Our security > AD made a presentation in the TLS working group yesterday and the > message is that we want everyone to use TLS for everything. A bit of a confused message is inevitable in a rough consensus = organization.=20 We're participating as individuals and have different perspectives and=20 positions as individuals. The work to form a rough consensus can be = messy.=20 But I hear your complaint and will talk to Tim to see if the two of us = can=20 agree on a more unified message. For starters, I would agree that when a security services layer is = needed in an=20 application protocol stack that TLS is likely the right mechanism to = provide=20 that layer. I'm not convinced the "SL" portion of "SASL" has any value = in=20 practice. > No one wants to design their protocols > once with Kerberos and once with TLS, no one want to review their > protocols twice. Experience has clearly shown that requiring two set = of > mechanisms (one for Kerb and one for TLS) adds a lot of unnecessary > complexity to what is already too complex. I'd agree that implementers only want to integrate one security services = layer.=20 But some implementers want their security services layer and identity = stack to=20 be as cleanly separated as possible so a tight binding between the two = is not=20 desirable. TLS only provides certificate-based identity today, a = mechanism=20 that is very different from other user identity services because it does = not=20 require the TLS stack to perform a user identity network lookup in the = middle=20 of the TLS handshake. Doing that means the TLS stack suddenly has to=20 communicate problems talking to the identity lookup service through the = TLS=20 stack and back to the application. > Not to mention the burden to > test two sets of mechanisms. We the IETF really should build a better > building block for future IETF standard protocols and deliver a = coherent > strategy/solution. It's more important to build a strategy/solution that can be deployed = and=20 sustained in the real world with multiple independent interoperable=20 implementations. > Non-IETF protocols that do not have a SASL variant do not even have a > choice, we have to integrate Kerberos into the TLS stack to get = Kerberos > to work, not to mention the practical reasons due to firewalls and NAT > traversal. An application protocol that needs user-level authentication and fails = to=20 include an authentication framing mechanism in the protocol is designed=20 incorrectly, and the fact some non-IETF protocols have that problem is = not a=20 reason to add complexity to IETF protocols. HTTP has such a framing = mechanism,=20 SSH has one, also SASL, GSSAPI and EAP include protocol abstractions = that could=20 be used to provide such a mechanism in any other application protocol. If you try to solve the general application-layer user authentication = problem=20 in the TLS stack, that adds a bunch of requirements to TLS that it = probably=20 shouldn't have if there's a desire to keep the stack simple. An example = would=20 be error messages suitable for end-user consumption and the language=20 negotiation necessary for such messages (SSH does this, for example). - Chris ------_=_NextPart_001_01C7CFA2.5B4CBE88 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [TLS] the use cases for GSS-based TLS and the plea for = integrating

Chris Newman wrote:
> TLS only provides certificate-based identity today, a mechanism
> that is very different from other user identity services because it = does not
> require the TLS stack to perform a user identity network lookup in = the middle
> of the TLS handshake.  Doing that means the TLS stack suddenly = has to
> communicate problems talking to the identity lookup service through = the TLS
> stack and back to the application.

Reading what you are saying, I suspect you have somewhat misunderstood = the proposal and the GSS-API abstraction in general.
Unfortunately I am on my way home. Thanks for the delay in the airport I = am still phyiscally in Chicago. I would suggest for you to talk with Sam = Hartman before making further comments on the proposal or GSS-API.

thanks,
--larry
-----Original Message-----
From: Chris Newman [mailto:Chris.Newman@Sun.COM]
= Sent: Thu 7/26/2007 9:00 AM
To: Larry Zhu; martin.rex@sap.com
Cc: tls@ietf.org
Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for = integrating

Larry Zhu wrote on 7/25/07 12:48 -0700:
> For use cases, please review my slides and the meeting minutes for = the
> TLS working group. I would like to recap the main points below:

I will look at them.

> Methodology wise the way to deal with complexity is to build = abstraction
> layers. GSS-API is ideal for encapsulating the described = complexity.

Abstraction layers can decrease complexity, increase complexity, cause = "data
hiding" (good), and "data losing" (bad).  How = abstraction layers are hooked
together matters a great deal.  There's an abstraction layer = between
applications and TLS.  There's an abstraction layer between = applications and
SASL/GSSAPI.  But what you're proposing shoves GSSAPI behind the = TLS
abstraction, creating a clear case of "data losing" in the = abstraction model.
That would require punching holes through the TLS abstraction layer so = the
application can control both GSSAPI and any back channels GSSAPI uses to = talk
to user authentication repositories or trusted third parties.

> We strongly believe there is a confusing message in IETF. Our = security
> AD made a presentation in the TLS working group yesterday and = the
> message is that we want everyone to use TLS for everything.

A bit of a confused message is inevitable in a rough consensus = organization.
We're participating as individuals and have different perspectives = and
positions as individuals.  The work to form a rough consensus can = be messy.
But I hear your complaint and will talk to Tim to see if the two of us = can
agree on a more unified message.

For starters, I would agree that when a security services layer is = needed in an
application protocol stack that TLS is likely the right mechanism to = provide
that layer.  I'm not convinced the "SL" portion of = "SASL" has any value in
practice.

> No one wants to design their protocols
> once with Kerberos and once with TLS, no one want to review = their
> protocols twice.  Experience has clearly shown that requiring = two set of
> mechanisms (one for Kerb and one for TLS) adds a lot of = unnecessary
> complexity to what is already too complex.

I'd agree that implementers only want to integrate one security services = layer.
But some implementers want their security services layer and identity = stack to
be as cleanly separated as possible so a tight binding between the two = is not
desirable.  TLS only provides certificate-based identity today, a = mechanism
that is very different from other user identity services because it does = not
require the TLS stack to perform a user identity network lookup in the = middle
of the TLS handshake.  Doing that means the TLS stack suddenly has = to
communicate problems talking to the identity lookup service through the = TLS
stack and back to the application.

> Not to mention the burden to
> test two sets of mechanisms. We the IETF really should build a = better
> building block for future IETF standard protocols and deliver a = coherent
> strategy/solution.

It's more important to build a strategy/solution that can be deployed = and
sustained in the real world with multiple independent interoperable
implementations.

> Non-IETF protocols that do not have a SASL variant do not even have = a
> choice, we have to integrate Kerberos into the TLS stack to get = Kerberos
> to work, not to mention the practical reasons due to firewalls and = NAT
> traversal.

An application protocol that needs user-level authentication and fails = to
include an authentication framing mechanism in the protocol is = designed
incorrectly, and the fact some non-IETF protocols have that problem is = not a
reason to add complexity to IETF protocols.  HTTP has such a = framing mechanism,
SSH has one, also SASL, GSSAPI and EAP include protocol abstractions = that could
be used to provide such a mechanism in any other application = protocol.

If you try to solve the general application-layer user authentication = problem
in the TLS stack, that adds a bunch of requirements to TLS that it = probably
shouldn't have if there's a desire to keep the stack simple.  An = example would
be error messages suitable for end-user consumption and the language
negotiation necessary for such messages (SSH does this, for = example).

            &= nbsp;   - Chris

------_=_NextPart_001_01C7CFA2.5B4CBE88-- --===============1063126754== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1063126754==-- From tls-bounces@lists.ietf.org Thu Jul 26 14:00:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE7d7-0006BG-MR; Thu, 26 Jul 2007 14:00:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE7d5-00067A-Ue for tls@ietf.org; Thu, 26 Jul 2007 14:00:03 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE7d4-0005Je-Gn for tls@ietf.org; Thu, 26 Jul 2007 14:00:03 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id TAA20484; Thu, 26 Jul 2007 19:59:44 +0200 (MESZ) From: Martin Rex Message-Id: <200707261759.l6QHxg1O016582@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Thu, 26 Jul 2007 19:59:42 +0200 (MEST) In-Reply-To: <873azbgob1.fsf@mocca.josefsson.org> from "Simon Josefsson" at Jul 26, 7 05:46:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Chris.Newman@Sun.COM, tls@ietf.org Subject: [TLS] Re: the use cases for GSS-based TLS and the plea for integrating X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org There is currently one proposal from Microsoft available as an ID and I'm planning to come up with an ID in the September/October timeframe based on the comments that I've made. The two approaches are in some aspect fundamentally different. One thing that I particularly dislike about the current ID is its total silence/ignorance about the necessary changes to add this to existing implementations and software architectures. Personally, this impact on the installed base, existing implementations and existing modularization and software architecture is a significant concern when comparing the merits of different approaches. YMMV. a) draft-ietf-santesson-tls-gssapi: - uses GSS-API as a key distribution scheme in order to seed a TLS-PSK cihpersuite. So the (PS)Key is not really pre-shared, it is created for and distributed with the very same TLS handshake # of round-trips: without optimistic gssapi context token tls-handshake + gssapi-handshake with optimistic gssapi context token (e.g. SPNEGO+optimistic token): correct guess: tls-handshake + gssapi-handshake - 1 wrong guess: tls-handshake + gssapi-handshake advantages: * if the gssapi mechanism uses PK-ops-free context establishment the the TLS handshake can be performed entirely without PK-ops disadvantages: * works only with gssapi mechanisms that establish a shared session key during security context establishment (which essentially means: offer confidentiality message protection) * is currently limited to new gssapi mechanisms implementing the optional GSS_prf API extension * the entire GSS-API security context establishment MUST be performed completely inside the TLS handshake * requires major re-enginering of the TLS state machine and new handshake messages * will add at least one round-trip to the TLS-handshake if negotiation of gssapi mechanisms should be done and _NO_ optimistic gssapi context token scheme is used * will mess severly with the protocol stack software architecture because the calling application will likely want to get access to gssapi extensions/features/attributes from the gssapi context and object handles that are being using deeply within and owned/managed by TLS during the TLS handshake * does not provide identity protection for the client * does not improve security (weaknesses) over a regular gssapi authentication without TLS b) my (developing) concept/idea which I have been buiding up during my numerous postings last week on the TLS mailing list. - uses GSS-API as an additional or alternative authentication method for one or both peers on top of a regular TLS ciphersuite and after an almost vanilla TLS handshake (using a TLS Hello extension for determining availabilty of the protocol extension and selection of a common gssapi mechanism), plus three additions to TLS: - (preferably) an additional content type at the SSL/TLS record layer and API calls/extensions to exchange gssapi context establishment tokens following the TLS handshake between the peers - the possibility to update (using XOR) the pre-master secret and re-generate a new session key of a newly established SSL session synchronously (maybe this should use yet another content type similar to change_cipher_spec). - the possibility to attach an opaque (size-limited) flat-memory object to an SSL session (+session cache entry) where a seperate software module "TLSplus" above TLS can store those gssapi attributes which the application caller might want or need on SSL/TLS session resume I think it would be good to combine the attaching of additional attributes and the update of the pre-master secret and keying material # of round-trips: regular (and this includes mech negotiation): tls-handshake + gssapi-handshake with TLS-finished piggyback optim.: tls-handshake + gssapi-handshake - 1 the additional TLSplus module will have to implement most of what represents gssapi-over-tls, i.e. set up the (simple OID) list of gssapi mechanisms for the TLS Hello extension, determine after the TLS handshake whether gssapi-over-tls and which mechanism OID was negotiated in the Hello extension, perform the GSS-API handshake when the TLS handshake is finished (optionally using the (clients) TLS finished message(s) as channel bindings, update the TLS session crypto keys if the gssapi mechanism can provide entropy for a cryptographic binding, collect gssapi attributes which the app cares about, serialize them into a flat memory object and ask TLS to attach them to the SSL session. disadvantages: * will incur the (CPU) overhead of a regular TLS handshake in addition to the gssapi authentication exchange, which normally means a TLS ciphersuite with PK-ops * will require one additional round-trip if NO optimization is implemented for the client to piggyback the messagee with the initiators first gssapi context token onto the clients TLS finished message advantages: * should work with most existing and future TLS cipher suites * will work with the entire installed based of gssapi mechs, no changes necessary (aside from potential ABI issues). * obviates SPNEGO and multi-mech-glues * should work with authentication-only gssapi mechanism just fine (it doesn't improve the security of the gssapi authentication exchange itself, though) * should work with SASL instead of GSS-API authentication handshakes (at least non-interactive ones) * requires only mild modifications of existing TLS implementations * should be doable even as a low-impact SSLv3 extension, not only TLS v1.x * client identity protection because the entire gssapi handshake is performed under TLS protection * a combination of server-authentication based on SSL server cert and client authentication based on gssapi client authentication is quite possible, * high orthogonality to the TLS protocol, permitting completely independent evolution of gss-api and the TLS protocol stack * clear seperation of protocol stacks and abstractions, TLS doesn't have to mess with GSS-API, GSS-API doesn't have to mess with TLS, TLSplus can be custom tailored to provide the amount of gssapi attribute persistence that the application needs. in order to improve interoperability and to ease the use in heterogeneous environments, the TLSplus layer should have a self-signed certificate generated in case the customer does not (want to) setup a PKI so that non-anonymous TLS ciphersuites can be used. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 26 15:45:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9HL-0001Je-24; Thu, 26 Jul 2007 15:45:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9HK-0001JY-2T for tls@ietf.org; Thu, 26 Jul 2007 15:45:42 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE9HJ-0006SC-0j for tls@ietf.org; Thu, 26 Jul 2007 15:45:41 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6QJjdPt000401 for ; Thu, 26 Jul 2007 19:45:39 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLS00J01XDWSX00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for tls@ietf.org; Thu, 26 Jul 2007 13:45:39 -0600 (MDT) Received: from [10.1.110.5] (dhcp-1695.ietf69.org [130.129.22.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLS00GSYXK1U730@mail-amer.sun.com>; Thu, 26 Jul 2007 13:45:39 -0600 (MDT) Date: Thu, 26 Jul 2007 14:46:21 -0500 From: Chris Newman Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating In-reply-to: To: Larry Zhu Message-id: <7CD9366321AC463125D19ED4@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Larry Zhu wrote on 7/26/07 9:31 -0700: > Chris Newman wrote: >> TLS only provides certificate-based identity today, a mechanism >> that is very different from other user identity services because it does not >> require the TLS stack to perform a user identity network lookup in the middle >> of the TLS handshake. Doing that means the TLS stack suddenly has to >> communicate problems talking to the identity lookup service through the TLS >> stack and back to the application. > > Reading what you are saying, I suspect you have somewhat misunderstood the > proposal and the GSS-API abstraction in general. That's entirely possible, which is why I wanted to engage in this debate before something arrives in front of the IESG and I have to make a decision. As applications area director, I have to invest time to learn how important infrastructure proposals are likely to impact Internet applications in general, but I have no illusions of being a security expert (rather I'm an application expert with a focus on security technology). This issue is too important for me to decide alone, so I'm asking for help from the community to consider these issues. > Unfortunately I am on my way home. Thanks for the delay in the airport I am > still phyiscally in Chicago. I wish you a safe flight home. FYI, I very much appreciate your participation in the IETF process. Technical debate is messy but when the parties involved all want the best possible outcome for the Internet, it is worth the effort. I do want to see Kerberos, TLS and applications such as HTTP, SMTP, IMAP, POP combined in a way that is most likely to be widely deployed by multiple vendors. > I would suggest for you to talk with Sam Hartman I will certainly do that. However, I recommend you talk to application developers who consume TLS and GSSAPI/SSPI/SASL/EAP APIs to see how they feel about these issues. - Chris _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 26 16:00:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9VM-00074i-2F; Thu, 26 Jul 2007 16:00:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9VK-00071w-4U for tls@ietf.org; Thu, 26 Jul 2007 16:00:10 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE9VJ-0006lC-Oo for tls@ietf.org; Thu, 26 Jul 2007 16:00:10 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 85DD33BE8D; Thu, 26 Jul 2007 22:00:08 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28552-03-14; Thu, 26 Jul 2007 22:00:08 +0200 (CEST) Received: from [130.129.18.102] (dhcp-1266.ietf69.org [130.129.18.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 6AD5E3BE67; Thu, 26 Jul 2007 22:00:07 +0200 (CEST) Message-ID: <46A8FD4F.7050203@it.su.se> Date: Thu, 26 Jul 2007 22:00:15 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Chris Newman Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.951 tagged_above=-99 required=7 tests=[AWL=0.361, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org > > I'd agree that implementers only want to integrate one security > services layer. But some implementers want their security services > layer and identity stack to be as cleanly separated as possible so a > tight binding between the two is not desirable. TLS only provides > certificate-based identity today, a mechanism that is very different > from other user identity services because it does not require the TLS > stack to perform a user identity network lookup in the middle of the > TLS handshake. Doing that means the TLS stack suddenly has to > communicate problems talking to the identity lookup service through > the TLS stack and back to the application. > Username+password has the same property right? Would you support a password-based scheme inside TLS or would you support removing authentication from TLS entierly? Cheers Leif _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 26 17:45:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEB9K-0006MH-CY; Thu, 26 Jul 2007 17:45:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEB9I-0006MB-OK for tls@ietf.org; Thu, 26 Jul 2007 17:45:32 -0400 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEB9I-0001Lr-3M for tls@ietf.org; Thu, 26 Jul 2007 17:45:32 -0400 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l6QLjVcq027977 for ; Thu, 26 Jul 2007 17:45:31 -0400 (EDT) Received: from 144.51.60.33 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Thu, 26 Jul 2007 17:45:32 -0400 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jul 2007 17:45:31 -0400 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 Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating Date: Thu, 26 Jul 2007 17:45:49 -0400 Message-ID: In-Reply-To: <46A8FD4F.7050203@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] the use cases for GSS-based TLS and the plea for integrating Thread-Index: AcfPv5hkOheR3EYPTXOMcEjnb83aCwABhrsQ References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> <46A8FD4F.7050203@it.su.se> From: "Kemp, David P." To: X-OriginalArrivalTime: 26 Jul 2007 21:45:31.0985 (UTC) FILETIME=[4A48DC10:01C7CFCE] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15324001 X-TM-AS-Result: : Yes--12.770300-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwNjI5MC0xMjE0?= =?us-ascii?B?MTQtNzAxMzg3LTcwMDc1Ni03MDIxMTMtMTIxMzcxLTcwMTU3Ni03?= =?us-ascii?B?MDU1MjYtNzAyMDQ0LTEwNjQyMC03MDE3NDEtNzAxOTM3LTcxMDk3?= =?us-ascii?B?MC0xMjExMDgtNzA0NDIxLTcwODE3OS03MDEwMDUtMTM5MDA2LTcw?= =?us-ascii?B?MDMxNi03MDEyMDctNzAyMzU4LTEzOTAxMC03MDA3MjYtNzAzMzY2?= =?us-ascii?B?LTcwNzMyMS03MDA5OTQtNzEwNDQyLTcwMjEzMS03MDcxMTQtNzA5?= =?us-ascii?B?MDY1LTcwMjcyNi0xMTMyMjgtNzAwNzgzLTcwMTQ1NS03MDA0MDEt?= =?us-ascii?B?NzAxMjQ5LTEzOTcwMy03MDAwNDctMTQ4MDM5LTE0ODA1MC0yMDA0?= =?us-ascii?B?Mg==?= X-Spam-Score: -1.0 (-) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Umm, is that a trick question? Symmetric mechanisms (static passwords, OTP, Kerberos, etc) all have the property of requiring communication with an identity provider in real-time to authenticate a user (except for pre-placed keys, a non-scalable technique that is not under consideration for TLS even though it is supported in IPSec). Asymmetric (certificate-based) mechanisms can authenticate a user without communicating with an identity provider and without giving one party the ability to masquerade as the other. One certainly would not want to remove asymmetric authentication from TLS (i.e., it should remain mandatory to implement). The discussion concerns whether to add symmetric authentication inside TLS and if not, how to bind TLS sessions to symmetric authentication at a layer above TLS. -----Original Message----- From: Leif Johansson [mailto:leifj@it.su.se]=20 Sent: Thursday, July 26, 2007 4:00 PM To: Chris Newman Cc: tls@ietf.org Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating > > I'd agree that implementers only want to integrate one security > services layer. But some implementers want their security services > layer and identity stack to be as cleanly separated as possible so a > tight binding between the two is not desirable. TLS only provides > certificate-based identity today, a mechanism that is very different > from other user identity services because it does not require the TLS > stack to perform a user identity network lookup in the middle of the > TLS handshake. Doing that means the TLS stack suddenly has to > communicate problems talking to the identity lookup service through > the TLS stack and back to the application. > Username+password has the same property right? Would you support a password-based scheme inside TLS or would you support removing authentication from TLS entierly? Cheers Leif _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 26 17:53:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEBHC-0005Fw-B3; Thu, 26 Jul 2007 17:53:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEBHB-0005Fq-Kv for tls@ietf.org; Thu, 26 Jul 2007 17:53:41 -0400 Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEBHB-0001UY-6W for tls@ietf.org; Thu, 26 Jul 2007 17:53:41 -0400 Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id l6QLremw024920 for ; Thu, 26 Jul 2007 17:53:40 -0400 (EDT) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.6.1) with ESMTP id md50000058800.msg for ; Thu, 26 Jul 2007 17:54:57 -0400 Message-ID: <46A91838.5050705@secure-endpoints.com> Date: Thu, 26 Jul 2007 17:55:04 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Chris.Newman@Sun.COM Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> <7CD9366321AC463125D19ED4@446E7922C82D299DB29D899F> In-Reply-To: <7CD9366321AC463125D19ED4@446E7922C82D299DB29D899F> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://pgp.mit.edu X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Thu, 26 Jul 2007 17:54:57 -0400 (not processed: message from valid local sender) X-Lookup-Warning: EHLO lookup on [192.168.1.13] does not match 24.193.47.99 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com 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: , Content-Type: multipart/mixed; boundary="===============1852136673==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1852136673== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000104090901050803050509" This is a cryptographically signed message in MIME format. --------------ms000104090901050803050509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Chris Newman wrote: > I will certainly do that. However, I recommend you talk to > application developers who consume TLS and GSSAPI/SSPI/SASL/EAP APIs > to see how they feel about these issues. > Chris: If I am reading you correctly, you would like to see proposals for example describing how the Windows SSPI and OpenSSL among other TLS implementations would need to be modified to support the described functionality. I think that this is a very important consideration and I would be happy to propose changes for OpenSSL as I was involved in adding the support for TLS KRB5 to OpenSSL many years ago. Jeffrey Altman --------------ms000104090901050803050509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA3MjYyMTU1MDRaMCMGCSqGSIb3DQEJBDEWBBScXYHQ RBeBWY2t7uGupI3AFa9LrTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAaeJjA/1mVew6ETwtph7Cenua6y1X567hbLwt3oYv23AYHVk1jhI4 B8sjvZAV2tGepHK53dV2JdYduVEReSJaOwqO3Xj06HYVDd0eONTkmnoQdSNzgO+Fy0NwfSxI xV01j7qJ3Qb0Tx/Mgi74Y2uc0zTbz9yJsu1I/d1kwg02Tx92rEj0WIVRpt3MjIGdwOa0hU2D 4S0jFvrntu8vegFx2rVLI1pRrVPepBBW2/cbSkYV/Tyi6wva7Hb82ajT42SxfS7UTpIoJod1 nniwS6vIEiPukA/0JDNYPSX1YIda38IXKQ/GdTBMlXIoT+a+gMCvvSIMzgKAmXBfr9HWnQHm xwAAAAAAAA== --------------ms000104090901050803050509-- --===============1852136673== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1852136673==-- From tls-bounces@lists.ietf.org Thu Jul 26 18:21:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEBiN-0004WE-Sw; Thu, 26 Jul 2007 18:21:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEBiN-0004W8-Fw for tls@ietf.org; Thu, 26 Jul 2007 18:21:47 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEBiL-0001wQ-RS for tls@ietf.org; Thu, 26 Jul 2007 18:21:47 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id D45D474098; Fri, 27 Jul 2007 00:21:44 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27790-01-77; Fri, 27 Jul 2007 00:21:44 +0200 (CEST) Received: from [130.129.18.102] (dhcp-1266.ietf69.org [130.129.18.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id A876E74012; Fri, 27 Jul 2007 00:21:43 +0200 (CEST) Message-ID: <46A91E7E.4080608@it.su.se> Date: Fri, 27 Jul 2007 00:21:50 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Kemp, David P." Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> <46A8FD4F.7050203@it.su.se> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.596 tagged_above=-99 required=7 tests=[AWL=0.716, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Kemp, David P. wrote: > Umm, is that a trick question? > Yes. > Symmetric mechanisms (static passwords, OTP, Kerberos, etc) all have > the property of requiring communication with an identity provider > in real-time to authenticate a user (except for pre-placed keys, a > non-scalable technique that is not under consideration for TLS even > though it is supported in IPSec). > > Asymmetric (certificate-based) mechanisms can authenticate a user > without communicating with an identity provider and without giving > one party the ability to masquerade as the other. > > One certainly would not want to remove asymmetric authentication > from TLS (i.e., it should remain mandatory to implement). The > discussion concerns whether to add symmetric authentication inside > TLS and if not, how to bind TLS sessions to symmetric authentication > at a layer above TLS. For the sake clarifying this discussion I'm not sure I understand what you mean by an symmetric form of authentication. Afaik there is authentication and other authentication. Both you and Chris have a point in that there is a difference between X.509 based authentication for TLS and many other mechanism but so what? Chris makes the case that errors from (say) network-related problems which occured out-of-band (wrt TLS) must be communicated through TLS but so must problems related to path construction and path validation in the X.509 case, right? Having said that I agree fully that a clean stack is a good stack and I look forward to reading Martins proposal. Cheers Leif _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 26 19:14:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECXj-00030Y-8F; Thu, 26 Jul 2007 19:14:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECXi-000309-3R for tls@ietf.org; Thu, 26 Jul 2007 19:14:50 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IECXg-0002te-Ik for tls@ietf.org; Thu, 26 Jul 2007 19:14:50 -0400 Received: from [172.31.21.235] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l6QNEkn4005519 for ; Fri, 27 Jul 2007 02:14:46 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> <46A8FD4F.7050203@it.su.se> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating Date: Thu, 26 Jul 2007 18:14:39 -0500 To: tls@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I disagree with that characterization of certificate-based authentication. You may not need to communicate with an identity provider, but you do need to validate the certificate. This necessarily implies checking for revocation. Now this could be done using CRL fetching, or OCSP or SCVP, but it usually means external communications. Yes, I know that it's possible to cache CRLs and that the online protocols have modes by which the client makes the verification, but you can't say that verifying a certificate does not involve external communications. On Jul 26, 2007, at 4:45 PM, Kemp, David P. wrote: > Umm, is that a trick question? > > Symmetric mechanisms (static passwords, OTP, Kerberos, etc) all have > the property of requiring communication with an identity provider > in real-time to authenticate a user (except for pre-placed keys, a > non-scalable technique that is not under consideration for TLS even > though it is supported in IPSec). > > Asymmetric (certificate-based) mechanisms can authenticate a user > without communicating with an identity provider and without giving > one party the ability to masquerade as the other. > > One certainly would not want to remove asymmetric authentication > from TLS (i.e., it should remain mandatory to implement). The > discussion concerns whether to add symmetric authentication inside > TLS and if not, how to bind TLS sessions to symmetric authentication > at a layer above TLS. > > > > > -----Original Message----- > From: Leif Johansson [mailto:leifj@it.su.se] > Sent: Thursday, July 26, 2007 4:00 PM > To: Chris Newman > Cc: tls@ietf.org > Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for > integrating > > >> >> I'd agree that implementers only want to integrate one security >> services layer. But some implementers want their security services >> layer and identity stack to be as cleanly separated as possible so a >> tight binding between the two is not desirable. TLS only provides >> certificate-based identity today, a mechanism that is very different >> from other user identity services because it does not require the TLS >> stack to perform a user identity network lookup in the middle of the >> TLS handshake. Doing that means the TLS stack suddenly has to >> communicate problems talking to the identity lookup service through >> the TLS stack and back to the application. >> > Username+password has the same property right? Would you support a > password-based > scheme inside TLS or would you support removing authentication from > TLS > entierly? > > Cheers Leif > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 09:49:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQCI-0005kb-1q; Fri, 27 Jul 2007 09:49:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQCG-0005kV-Qe for tls@ietf.org; Fri, 27 Jul 2007 09:49:36 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEQCE-0004cH-Tb for tls@ietf.org; Fri, 27 Jul 2007 09:49:36 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6RDnYFZ004408 for ; Fri, 27 Jul 2007 13:49:34 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLU00B01BJ4OQ00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for tls@ietf.org; Fri, 27 Jul 2007 07:49:34 -0600 (MDT) Received: from [10.1.110.5] (dhcp-1695.ietf69.org [130.129.22.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLU006G2BQJCK10@mail-amer.sun.com>; Fri, 27 Jul 2007 07:49:34 -0600 (MDT) Date: Fri, 27 Jul 2007 08:50:17 -0500 From: Chris Newman Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating In-reply-to: <46A8FD4F.7050203@it.su.se> To: Leif Johansson Message-id: <97106756681A40418FDFFE56@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> <46A8FD4F.7050203@it.su.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Leif Johansson wrote on 7/26/07 22:00 +0200: >> I'd agree that implementers only want to integrate one security >> services layer. But some implementers want their security services >> layer and identity stack to be as cleanly separated as possible so a >> tight binding between the two is not desirable. TLS only provides >> certificate-based identity today, a mechanism that is very different >> from other user identity services because it does not require the TLS >> stack to perform a user identity network lookup in the middle of the >> TLS handshake. Doing that means the TLS stack suddenly has to >> communicate problems talking to the identity lookup service through >> the TLS stack and back to the application. >> > Username+password has the same property right? Yes. > Would you support a password-based scheme inside TLS or Most schemes that embed user authentication in the TLS state machine have similar issues. Since GSSAPI is a framework for authentication mechanisms in general, it inherits the superset of all authentication-identity-related issues. > would you support removing authentication from TLS entierly? No. Server certificate authentication is useful in practice as part of today's interim solution to authentication despite certain dubious qualities. As client certificate authentication is a rarely used feature of TLS, it's questionable whether it should have been included in the original design. However, given that the mechanism has deployed well in implementations and is actually used in some enclaves, it would be far too disruptive to change now. Client certificates are also less problematic because the identity service lookup can be deferred to the application layer using a mechanism such as SASL EXTERNAL or IMAP "* PREAUTH". - Chris _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 10:02:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQOd-0007Rb-BV; Fri, 27 Jul 2007 10:02:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQOb-0007RW-PC for tls@ietf.org; Fri, 27 Jul 2007 10:02:21 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEQOb-0005As-4g for tls@ietf.org; Fri, 27 Jul 2007 10:02:21 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6RE2K58020400 for ; Fri, 27 Jul 2007 14:02:20 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLU00301C7CNI00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for tls@ietf.org; Fri, 27 Jul 2007 08:02:20 -0600 (MDT) Received: from [10.1.110.5] (dhcp-1695.ietf69.org [130.129.22.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLU007H7CBTLV00@mail-amer.sun.com>; Fri, 27 Jul 2007 08:02:20 -0600 (MDT) Date: Fri, 27 Jul 2007 09:03:04 -0500 From: Chris Newman Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating In-reply-to: <46A91838.5050705@secure-endpoints.com> To: jaltman@secure-endpoints.com Message-id: <4326E17DC83C408C88F440C0@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> <7CD9366321AC463125D19ED4@446E7922C82D299DB29D899F> <46A91838.5050705@secure-endpoints.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Jeffrey Altman wrote on 7/26/07 17:55 -0400: > Chris Newman wrote: >> I will certainly do that. However, I recommend you talk to >> application developers who consume TLS and GSSAPI/SSPI/SASL/EAP APIs >> to see how they feel about these issues. >> > Chris: > > If I am reading you correctly, you would like to see proposals for > example describing how the Windows SSPI and OpenSSL among other TLS > implementations would need to be modified to support the described > functionality. I think that this is a very important consideration and > I would be happy to propose changes for OpenSSL as I was involved in > adding the support for TLS KRB5 to OpenSSL many years ago. Yes. And it's not just changes to the TLS stacks, but also to the applications that consume the TLS stacks. I also encourage serious consideration of alternate approaches that involve fewer changes to the TLS stack. - Chris _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 10:07:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQTI-0002Li-52; Fri, 27 Jul 2007 10:07:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQTH-0002Ld-RF for tls@lists.ietf.org; Fri, 27 Jul 2007 10:07:11 -0400 Received: from moe.its.auckland.ac.nz ([130.216.12.35] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEQTF-0004ue-KV for tls@lists.ietf.org; Fri, 27 Jul 2007 10:07:11 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2E9D14804E7 for ; Sat, 28 Jul 2007 02:07:06 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RlPjXMzeDS2 for ; Sat, 28 Jul 2007 02:07:06 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1390C4804E6 for ; Sat, 28 Jul 2007 02:07:06 +1200 (NZST) Received: from eris.cs.auckland.ac.nz (eris.cs.auckland.ac.nz [130.216.33.46]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id AE758D14CFC for ; Sat, 28 Jul 2007 02:07:05 +1200 (NZST) Received: from 125-238-114-81.broadband-telecom.global-gateway.net.nz (125-238-114-81.broadband-telecom.global-gateway.net.nz [125.238.114.81]) by webmail.cs.auckland.ac.nz (Horde) with HTTP for ; Sat, 28 Jul 2007 02:07:02 +1200 Message-ID: <20070728020702.2x3rc53g7bksocc0@webmail.cs.auckland.ac.nz> Date: Sat, 28 Jul 2007 02:07:02 +1200 From: pgut001@cs.auckland.ac.nz To: tls@lists.ietf.org Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> <46A8FD4F.7050203@it.su.se> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.1) X-Originating-IP: 125.238.114.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org "Kemp, David P." writes: > Symmetric mechanisms (static passwords, OTP, Kerberos, etc) all have the > property of requiring communication with an identity provider in real-time to > authenticate a user (except for pre-placed keys, a non-scalable > technique that > is not under consideration for TLS even though it is supported in IPSec). > > Asymmetric (certificate-based) mechanisms can authenticate a user without > communicating with an identity provider and without giving one party the > ability to masquerade as the other. > > One certainly would not want to remove asymmetric authentication from TLS > (i.e., it should remain mandatory to implement). I realise this has the potential to open up a huge can of worms here, but I can't let this one pass by: "shared keys/passwords/whatever don't scale" is one of the most persistent myths on computer security. 99.99% of all authentication is done via pre-shared keys/passwords, including pretty much arbitrarily large infrastructures like eBay, Amazon, Gmail, any ISP using RADIUS, and . The ones that we know definitely don't scale well in comparison are all the others: PKI, Kerberos, yadda yadda yadda, and in particular the asymmetric-auth ones. For how many more years do we have to keep flogging the PKI corpse? If it worked as intended, the multibillion-dollar phishing industry wouldn't exist. Why keep it mandatory to implement something that very demonstrably doesn't work? Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 10:48:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IER72-0004Ub-NN; Fri, 27 Jul 2007 10:48:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IER71-0004ML-JV for tls@ietf.org; Fri, 27 Jul 2007 10:48:15 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IER71-0005vs-2V for tls@ietf.org; Fri, 27 Jul 2007 10:48:15 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6RElnhc003057 for ; Fri, 27 Jul 2007 17:48:12 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 17:48:07 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 17:48:07 +0300 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, 27 Jul 2007 17:48:05 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF69 TLS WG summary & minutes Thread-Index: AcfQXSP+NhX5KVafQ3WiaGe+jfrMdw== From: To: X-OriginalArrivalTime: 27 Jul 2007 14:48:07.0647 (UTC) FILETIME=[251BE6F0:01C7D05D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [TLS] IETF69 TLS WG summary & minutes X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org The TLS WG summary and preliminary minutes are now=20 available: http://www3.ietf.org/proceedings/07jul/minutes/tls.txt If you have any corrections or additions, please send them to me & Eric. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 11:11:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERTa-0007au-9J; Fri, 27 Jul 2007 11:11:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERTZ-0007ao-5v for tls@ietf.org; Fri, 27 Jul 2007 11:11:33 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IERTY-0006jR-Ls for tls@ietf.org; Fri, 27 Jul 2007 11:11:33 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA15268; Fri, 27 Jul 2007 17:11:26 +0200 (MESZ) From: Martin Rex Message-Id: <200707271508.l6RF8I9S018387@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating To: pgut001@cs.auckland.ac.nz Date: Fri, 27 Jul 2007 17:08:18 +0200 (MEST) In-Reply-To: <20070728020702.2x3rc53g7bksocc0@webmail.cs.auckland.ac.nz> from "pgut001@cs.auckland.ac.nz" at Jul 28, 7 02:07:02 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org pgut001@cs.auckland.ac.nz wrote: > > For how many more years do we have to keep flogging the PKI corpse? If it > worked as intended, the multibillion-dollar phishing industry wouldn't exist. > Why keep it mandatory to implement something that very demonstrably doesn't > work? I beg to differ. PKI does work. However, the marketplace has different preferences for a number of good reasons (IPR issues and operational costs among them). secret-key or shared-secret authentication comes in all different flavours and every human being learns the concept behind at a young age and not necessarily as a software implementation. public key technology and authentication through public key technology is different and its complexity appears to be beyond the scope of many non-technical people. Where it is used, pushed and advertised, it is often a part of a MUCH more complex thing called PKI and cluttered with the ridiculous bloat called X.509 certificate and the concept of "trusted (certification) authorities". If Public Key technology was more along the line of the original models of SSH and PGP, it would likely be used much more often. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 11:17:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERZY-0005jM-VF; Fri, 27 Jul 2007 11:17:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERZW-0005j8-N5 for tls@ietf.org; Fri, 27 Jul 2007 11:17:42 -0400 Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IERZB-0006sD-Rn for tls@ietf.org; Fri, 27 Jul 2007 11:17:42 -0400 Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id l6RFHIni018509 for ; Fri, 27 Jul 2007 11:17:19 -0400 (EDT) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.6.1) with ESMTP id md50000058868.msg for ; Fri, 27 Jul 2007 11:18:36 -0400 Message-ID: <46AA0CC6.8060707@secure-endpoints.com> Date: Fri, 27 Jul 2007 11:18:30 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: martin.rex@sap.com Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating References: <200707271508.l6RF8I9S018387@fs4113.wdf.sap.corp> In-Reply-To: <200707271508.l6RF8I9S018387@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.95.2 OpenPGP: url=http://pgp.mit.edu X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Fri, 27 Jul 2007 11:18:36 -0400 (not processed: message from valid local sender) X-Lookup-Warning: EHLO lookup on [192.168.1.13] does not match 24.193.47.99 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com 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: , Content-Type: multipart/mixed; boundary="===============0098255707==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0098255707== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030806080107020100020903" This is a cryptographically signed message in MIME format. --------------ms030806080107020100020903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin Rex wrote: > If Public Key technology was more along the line of the original > models of SSH and PGP, it would likely be used much more often. You might want to read Alma Whitten's paper "Why Johnny Can't Encrypt?". Its a usability study that explains why PGP is not usable for common folks. Jeffrey Altman --------------ms030806080107020100020903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184 9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d 1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1 AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk 0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr 5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU 3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM 94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3 UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA3MjcxNTE4MzBaMCMGCSqGSIb3DQEJBDEWBBQkkmxU Lfzup+9zfnnOJujXbHZUtDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ KoZIhvcNAQEBBQAEggEAmCcHZjv2MNLZR4JsVXevr2sc22teX59XAwTPbnpWJZhsGNRj1OMf 2B3cU3KwpUA9iYy53FgxIDOTPzK69BnYGxFA/YIeWCcSLd/eyybzpEa07gW/ksH8LWmNJvG6 POnno0Gr44scbFHVLXBEfVYoeg4t2C2zHIIg1ptPtTK0r+6OcSq9ExArmGY1S3D0KQkxF8XZ Fr89kPsHhRkuyG1N1BOKcwC69Bx3AU8VZ780d1yz8dRFrgcB9etA76fjae6aPGj20GFcarul v5+lDLsuLlse70gkwLfwEIqg+fYZLndgtU6hlYfMikJr6RUtm54pQO/h6U5Rw4gO2uo/yLbj xAAAAAAAAA== --------------ms030806080107020100020903-- --===============0098255707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0098255707==-- From tls-bounces@lists.ietf.org Fri Jul 27 11:25:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERhJ-0005f0-HD; Fri, 27 Jul 2007 11:25:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERhI-0005et-8J for tls@ietf.org; Fri, 27 Jul 2007 11:25:44 -0400 Received: from moe.its.auckland.ac.nz ([130.216.12.35] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERhD-0006pB-HD for tls@ietf.org; Fri, 27 Jul 2007 11:25:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9839E48055C; Sat, 28 Jul 2007 03:25:31 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFXqIKgLGRXl; Sat, 28 Jul 2007 03:25:31 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7CE5F480549; Sat, 28 Jul 2007 03:25:31 +1200 (NZST) Received: from eris.cs.auckland.ac.nz (eris.cs.auckland.ac.nz [130.216.33.46]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 1B150D14CFC; Sat, 28 Jul 2007 03:25:29 +1200 (NZST) Received: from 125-238-114-81.broadband-telecom.global-gateway.net.nz (125-238-114-81.broadband-telecom.global-gateway.net.nz [125.238.114.81]) by webmail.cs.auckland.ac.nz (Horde) with HTTP for ; Sat, 28 Jul 2007 03:25:25 +1200 Message-ID: <20070728032525.ziq6kvl6mk0sk0kg@webmail.cs.auckland.ac.nz> Date: Sat, 28 Jul 2007 03:25:25 +1200 From: pgut001@cs.auckland.ac.nz To: jaltman@secure-endpoints.com Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating References: <200707271508.l6RF8I9S018387@fs4113.wdf.sap.corp> <46AA0CC6.8060707@secure-endpoints.com> In-Reply-To: <46AA0CC6.8060707@secure-endpoints.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.1) X-Originating-IP: 125.238.114.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Jeffrey Altman writes: > Martin Rex wrote: >> If Public Key technology was more along the line of the original >> models of SSH and PGP, it would likely be used much more often. > You might want to read Alma Whitten's paper "Why Johnny Can't > Encrypt?". Its a usability study that explains why PGP is not usable > for common folks. If required I can add a shopping-list of other usability studies looking at why PKI in general is not usable for common folks. There's a summary in the slides at http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf, and a really long analysis (100-odd pages total, although it covers lots of other areas as well) at http://www.cs.auckland.ac.nz/~pgut001/pubs/man_usability.pdf. (Note that I'm not saying ditch PKI-based auth altogether, keep it if you want, but don't insist on making it a mandatory option in TLS if it doesn't work to protect users). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 11:28:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERjd-00086Z-UF; Fri, 27 Jul 2007 11:28:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERjd-00086S-0h for tls@lists.ietf.org; Fri, 27 Jul 2007 11:28:09 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERjb-0006sk-VZ for tls@lists.ietf.org; Fri, 27 Jul 2007 11:28:08 -0400 Received: by wa-out-1112.google.com with SMTP id j4so1051015wah for ; Fri, 27 Jul 2007 08:28:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=Gi/7QN09pEqHgDstAiqUeGOFVMO1ft3XO49wMK34Yl5KZ4O4Hd3uf8eOOSr7GP83BY0FSu/3anZizrRVuYEYcIGKoA+DzanGx/LVzeCSUPROl9T1a7RMyO41vIO2YcjukhKsgJ+WlIYFfTAeqsP2FoikjAt3ZnL8lD1n13uxA6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=TY7OlAOzzbZWmV8k/RYrUm9IKaSaSx5+4WyE0/ggRcmgKr6RYMLKZ6epC/tGHy71d9Tlf9hojGjj5uNhpaaFqHkVqNFfLVQg1HLsRkuxEJjdlMqUWSzdCCH7PVROU6m+YWR4Y6SNXG5MCz4gbpSACjxg/58pPr/Hhna/Xe1XmGE= Received: by 10.114.38.2 with SMTP id l2mr3041747wal.1185550087374; Fri, 27 Jul 2007 08:28:07 -0700 (PDT) Received: from ?172.16.1.114? ( [12.176.202.84]) by mx.google.com with ESMTPS id m31sm3084246wag.2007.07.27.08.28.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jul 2007 08:28:07 -0700 (PDT) In-Reply-To: <20070728020702.2x3rc53g7bksocc0@webmail.cs.auckland.ac.nz> References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> <46A8FD4F.7050203@it.su.se> <20070728020702.2x3rc53g7bksocc0@webmail.cs.auckland.ac.nz> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67C405F1-EAEA-46DF-A6F5-2F2397A32D43@gmail.com> Content-Transfer-Encoding: 7bit From: Kyle Hamilton Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating Date: Fri, 27 Jul 2007 08:28:04 -0700 To: pgut001@cs.auckland.ac.nz X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Jul 27, 2007, at 7:07 AM, pgut001@cs.auckland.ac.nz wrote: > "Kemp, David P." writes: >> Symmetric mechanisms (static passwords, OTP, Kerberos, etc) all >> have the >> property of requiring communication with an identity provider in >> real-time to >> authenticate a user (except for pre-placed keys, a non-scalable >> technique that >> is not under consideration for TLS even though it is supported in >> IPSec). ...ummm... the process of creating a key, sending a CSR, and then putting the returned certificate and certificate chain in place is a key pre-placement mechanism. Then again, it would also theoretically be possible to generate session IDs that you distribute to the clients, and then the clients use those pre-generated sessions to share the keys that way. (That path is fraught with so much peril that it's not worth considering for a general-purpose implementation, but I can envision a couple of specialized environments that it would be useful within.) >> Asymmetric (certificate-based) mechanisms can authenticate a user >> without >> communicating with an identity provider and without giving one >> party the >> ability to masquerade as the other. ...so OCSP was designed for a purpose that really didn't need to be filled. >> One certainly would not want to remove asymmetric authentication >> from TLS >> (i.e., it should remain mandatory to implement). I'm inclined to agree. It is too useful. However, the issue of enforcing X.509/PKIX is... questionable. > I realise this has the potential to open up a huge can of worms > here, but I > can't let this one pass by: "shared keys/passwords/whatever don't > scale" is > one of the most persistent myths on computer security. 99.99% of all > authentication is done via pre-shared keys/passwords, including > pretty much > arbitrarily large infrastructures like eBay, Amazon, Gmail, any ISP > using > RADIUS, and . The ones that we know definitely > don't scale > well in comparison are all the others: PKI, Kerberos, yadda yadda > yadda, and > in particular the asymmetric-auth ones. Why wouldn't the SSH paradigm work here? You have the public key associated with the address you're talking to. (and if the fingerprint popped up when you first connected to it, then a bank [for example] would be able to give you the fingerprint to verify against when you opened your account. Personally, I'd like to see the banks that open merchant accounts do the certifications of merchant identity. It would provide for a MUCH greater mechanism of knowing who to go after -- because if nothing else, the merchant account information could be used in a civil suit for garnishment. > For how many more years do we have to keep flogging the PKI > corpse? If it > worked as intended, the multibillion-dollar phishing industry > wouldn't exist. > Why keep it mandatory to implement something that very demonstrably > doesn't > work? There are circumstances for which it would work. It just doesn't work very well in the current implementation. That's the most important thing to consider: just because something doesn't work in the current implementation doesn't mean it doesn't work period. To be honest, X.500 (and the entire X.5** suite) is horribly unsuited for the purposes for which it was designed -- but LDAP (lightweight access to X.500-style directories) has been shown to be useful, which means that not all of the work that went into it was wasted. -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 11:34:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERq2-0004Be-KF; Fri, 27 Jul 2007 11:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERq1-0004BQ-2p for tls@lists.ietf.org; Fri, 27 Jul 2007 11:34:45 -0400 Received: from moe.its.auckland.ac.nz ([130.216.12.35] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERpz-00071K-Mt for tls@lists.ietf.org; Fri, 27 Jul 2007 11:34:45 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E7AE84804E6; Sat, 28 Jul 2007 03:34:42 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMgjkbuC4QSZ; Sat, 28 Jul 2007 03:34:42 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id CB7124804D5; Sat, 28 Jul 2007 03:34:42 +1200 (NZST) Received: from eris.cs.auckland.ac.nz (eris.cs.auckland.ac.nz [130.216.33.46]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 65AA7D14CFC; Sat, 28 Jul 2007 03:34:40 +1200 (NZST) Received: from 125-238-114-81.broadband-telecom.global-gateway.net.nz (125-238-114-81.broadband-telecom.global-gateway.net.nz [125.238.114.81]) by webmail.cs.auckland.ac.nz (Horde) with HTTP for ; Sat, 28 Jul 2007 03:34:36 +1200 Message-ID: <20070728033436.yw17ei6qfc80oo0g@webmail.cs.auckland.ac.nz> Date: Sat, 28 Jul 2007 03:34:36 +1200 From: pgut001@cs.auckland.ac.nz To: Kyle Hamilton Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> <46A8FD4F.7050203@it.su.se> <20070728020702.2x3rc53g7bksocc0@webmail.cs.auckland.ac.nz> <67C405F1-EAEA-46DF-A6F5-2F2397A32D43@gmail.com> In-Reply-To: <67C405F1-EAEA-46DF-A6F5-2F2397A32D43@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.1) X-Originating-IP: 125.238.114.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Kyle Hamilton writes: > Why wouldn't the SSH paradigm work here? You mean "connect to anything listening on port 22, then hand over your password in the clear (inside the SSH tunnel)"? How does it differ from the current phishing-enabling TLS usage of "connect to anything listening on port 443, then hand over your password in the clear (inside the TLS tunnel)"? (You're assuming that people check SSH key fingerprints. Please cite a real- world usability study supporting this assumption. NB: That's a booby-trapped question :-). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 12:00:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESEK-0002Ie-93; Fri, 27 Jul 2007 11:59:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESEI-0002IU-Tu for tls@ietf.org; Fri, 27 Jul 2007 11:59:50 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IESEI-0007t7-90 for tls@ietf.org; Fri, 27 Jul 2007 11:59:50 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id RAA11594; Fri, 27 Jul 2007 17:59:22 +0200 (MESZ) From: Martin Rex Message-Id: <200707271551.l6RFpb7W021006@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for To: pgut001@cs.auckland.ac.nz Date: Fri, 27 Jul 2007 17:51:37 +0200 (MEST) In-Reply-To: <20070728032525.ziq6kvl6mk0sk0kg@webmail.cs.auckland.ac.nz> from "pgut001@cs.auckland.ac.nz" at Jul 28, 7 03:25:25 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org pgut001@cs.auckland.ac.nz wrote: > > Jeffrey Altman writes: > > Martin Rex wrote: > >> If Public Key technology was more along the line of the original > >> models of SSH and PGP, it would likely be used much more often. > > You might want to read Alma Whitten's paper "Why Johnny Can't > > Encrypt?". Its a usability study that explains why PGP is not usable > > for common folks. > > If required I can add a shopping-list of other usability studies looking at > why PKI in general is not usable for common folks. There's a summary in the > slides at http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf, and a > really long analysis (100-odd pages total, although it covers lots of other > areas as well) at > http://www.cs.auckland.ac.nz/~pgut001/pubs/man_usability.pdf. > > (Note that I'm not saying ditch PKI-based auth altogether, keep it if you > want, but don't insist on making it a mandatory option in TLS if it doesn't > work to protect users). Joe Average also can not set up most things on his Windows PC, but for the simpler tasks, people can help each other. With PGP/SSH that has been possible and works fine. A few years ago I tried to use S/Mime to have someone who had S/Mime (but not PGP) configured send me stuff in an encrypted fashion via Email. I spent an hour until I gave up. All implementations of S/Mime-capable MUAs are so horribly broken that even someone with a technical understanding runs into brick walls everywhere. None of the MUAs (Outlook&Netscape Navigator) offered me to generate a self-signed S/Mime capable certificate. Trying to use existing or newly generated PKI-Credentials (which work just fine with SSL and GSS-API) proved to be impossible because of the braindead MUAs (it could be that it wasn't the MUAs fault but a braindead S/Mime spec that was causing the headaches). One of the problems with PKI that the technology is often contorted to push CA business models. And the other problem is that it has overloaded "PK credentials" with bloat of the "policy" category far beyond reason and is causing serious usability, supportability and interoperability problems for everyone who starts trying to use the technology for himself. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 12:05:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESJU-00012D-Sj; Fri, 27 Jul 2007 12:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESJT-000124-89 for tls@lists.ietf.org; Fri, 27 Jul 2007 12:05:11 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IESJS-0007pa-NS for tls@lists.ietf.org; Fri, 27 Jul 2007 12:05:11 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id SAA23295; Fri, 27 Jul 2007 18:04:52 +0200 (MESZ) From: Martin Rex Message-Id: <200707271604.l6RG4JlP021684@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating To: pgut001@cs.auckland.ac.nz Date: Fri, 27 Jul 2007 18:04:19 +0200 (MEST) In-Reply-To: <20070728033436.yw17ei6qfc80oo0g@webmail.cs.auckland.ac.nz> from "pgut001@cs.auckland.ac.nz" at Jul 28, 7 03:34:36 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org pgut001@cs.auckland.ac.nz wrote: > > Kyle Hamilton writes: > > Why wouldn't the SSH paradigm work here? > > You mean "connect to anything listening on port 22, then hand over your > password in the clear (inside the SSH tunnel)"? How does it differ from the > current phishing-enabling TLS usage of "connect to anything listening on port > 443, then hand over your password in the clear (inside the TLS tunnel)"? > > (You're assuming that people check SSH key fingerprints. Please cite a real- > world usability study supporting this assumption. NB: That's a booby-trapped > question :-). Nope. SSH automatically verifies the peers public key for your for EVERY but the first connect. You may use other out-of-band means to distribute the hosts SSH key besides answering the "do you confirm the fingerprint" on a first connect to a host. IMHO, one should only do the leap-of-faith if oneself has decided to perform an initial connect, and one should probably not do it when being asked by someone else to do it (to connect now). If you use PK-based instead of password-based client authentication with SSH, then you will at least to "disclose" a password accidentally. The underlying problem of bootstrapping the authentication process can not be avoided, independent of whether the authentication uses asymmetric crypto, symmetric crypto, or is a disclosing authentication. Using a pre-shared secret (like a password) to bootstrap a stronger PK-based authentication such as that from SSH is a possibility. In this scenario, however, the encrypted SSH tunnel is not magic Pixie dust that can fixed the security problem of that pre-shared authentication scheme that is being used to bootstrap. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 12:11:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESPT-00073s-2C; Fri, 27 Jul 2007 12:11:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESPR-00073L-GX for tls@lists.ietf.org; Fri, 27 Jul 2007 12:11:21 -0400 Received: from larry.its.auckland.ac.nz ([130.216.12.34] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IESPP-0007zS-Hb for tls@lists.ietf.org; Fri, 27 Jul 2007 12:11:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 36BB4183B0; Sat, 28 Jul 2007 04:11:17 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAupSpKGWBAs; Sat, 28 Jul 2007 04:11:17 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1A9AA183AD; Sat, 28 Jul 2007 04:11:17 +1200 (NZST) Received: from eris.cs.auckland.ac.nz (eris.cs.auckland.ac.nz [130.216.33.46]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id DF3BAD14D02; Sat, 28 Jul 2007 04:11:11 +1200 (NZST) Received: from 125-238-114-81.broadband-telecom.global-gateway.net.nz (125-238-114-81.broadband-telecom.global-gateway.net.nz [125.238.114.81]) by webmail.cs.auckland.ac.nz (Horde) with HTTP for ; Sat, 28 Jul 2007 04:11:06 +1200 Message-ID: <20070728041106.x7wvncwf36l4w8o0@webmail.cs.auckland.ac.nz> Date: Sat, 28 Jul 2007 04:11:06 +1200 From: pgut001@cs.auckland.ac.nz To: martin.rex@sap.com Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating References: <200707271604.l6RG4JlP021684@fs4113.wdf.sap.corp> In-Reply-To: <200707271604.l6RG4JlP021684@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.1) X-Originating-IP: 125.238.114.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex writes: > SSH automatically verifies the peers public key for your for EVERY > but the first connect. And that's exactly what phishing exploits. Going to a phishing site is always a first connect. SSH is no better than TLS when it comes to defending against phishing. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 12:17:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESVZ-00038F-QO; Fri, 27 Jul 2007 12:17:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESVY-00038A-4v for tls@ietf.org; Fri, 27 Jul 2007 12:17:40 -0400 Received: from larry.its.auckland.ac.nz ([130.216.12.34] helo=mailhost.auckland.ac.nz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IESVX-0008PB-LN for tls@ietf.org; Fri, 27 Jul 2007 12:17:40 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E62B1183B0; Sat, 28 Jul 2007 04:17:38 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwydOg-B3QSN; Sat, 28 Jul 2007 04:17:38 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C9A47183AD; Sat, 28 Jul 2007 04:17:38 +1200 (NZST) Received: from eris.cs.auckland.ac.nz (eris.cs.auckland.ac.nz [130.216.33.46]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 54698D14CFC; Sat, 28 Jul 2007 04:17:37 +1200 (NZST) Received: from 125-238-114-81.broadband-telecom.global-gateway.net.nz (125-238-114-81.broadband-telecom.global-gateway.net.nz [125.238.114.81]) by webmail.cs.auckland.ac.nz (Horde) with HTTP for ; Sat, 28 Jul 2007 04:17:33 +1200 Message-ID: <20070728041733.78oat8pscbk08ggo@webmail.cs.auckland.ac.nz> Date: Sat, 28 Jul 2007 04:17:33 +1200 From: pgut001@cs.auckland.ac.nz To: martin.rex@sap.com Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for References: <200707271551.l6RFpb7W021006@fs4113.wdf.sap.corp> In-Reply-To: <200707271551.l6RFpb7W021006@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.1) X-Originating-IP: 125.238.114.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex writes: > I spent an hour until I gave up. All implementations of S/Mime-capable > MUAs are so horribly broken that even someone with a technical > understanding runs into brick walls everywhere. It's not just S/MIME clients. The PARC study found that people with *PhDs in computer science* took, on average, over two hours to set up a cert for their own use (using paint-by-numbers screenshots as instructions), rated it as the hardest computer task they'd ever been asked to perform, and had no idea what they'd done to their computer when they were finished. PKI people who reviewed the paper were shocked at this, since they assumed that anyone could do it in a few minutes. (There's lots more like this in the two refs I gave. HCISec is a real eye- opener on the real-world effectiveness of security technology :-). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 14:03:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEU9V-0007U3-7W; Fri, 27 Jul 2007 14:03:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEU9U-0007Tw-0u for tls@ietf.org; Fri, 27 Jul 2007 14:03:00 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEU9T-00036x-GW for tls@ietf.org; Fri, 27 Jul 2007 14:02:59 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id UAA26041; Fri, 27 Jul 2007 20:02:54 +0200 (MESZ) From: Martin Rex Message-Id: <200707271802.l6RI2t8G027843@fs4113.wdf.sap.corp> Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating To: ynir@checkpoint.com (Yoav Nir) Date: Fri, 27 Jul 2007 20:02:55 +0200 (MEST) In-Reply-To: from "Yoav Nir" at Jul 26, 7 06:14:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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: , Errors-To: tls-bounces@lists.ietf.org Yoav Nir wrote: > > I disagree with that characterization of certificate-based > authentication. > > You may not need to communicate with an identity provider, but you do > need to validate the certificate. This necessarily implies checking > for revocation. Now this could be done using CRL fetching, or OCSP or > SCVP, but it usually means external communications. Nope, certificate validation does NOT imply certificate revocation checking. A CA may want to assert policies to do so, but that is an entirely different can of worms. A software architecture that performs certificate revoction checks by synchronously communicating with third parties over the network is likely to cause serious problem for the performance and availability of a service. I certainly don't mean to imply that certification checking is entirely useless. But my idea about a reasonable implementation of certificate revocation checking precludes synchronous communication with third parties, and therefore (accessing an) OCSP(-server). But even then, I would NOT do this within the TLS handshake itself. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 27 16:21:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEWJN-0002jA-Vg; Fri, 27 Jul 2007 16:21:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEWJM-0002j5-PS for tls@ietf.org; Fri, 27 Jul 2007 16:21:20 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IEWJJ-00060o-Be for tls@ietf.org; Fri, 27 Jul 2007 16:21:17 -0400 Received: (qmail 31429 invoked by uid 0); 27 Jul 2007 20:21:10 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.97.210.2) by woodstock.binhost.com with SMTP; 27 Jul 2007 20:21:10 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 27 Jul 2007 15:21:11 -0500 To: ietf-smime@imc.org,ietf-pkix@imc.org From: Russ Housley Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Message-Id: Excuse the cross-post, but this message seems relevant to these lists as well as TLS. Russ = = = = = = = = = = Date: Sat, 28 Jul 2007 04:17:33 +1200 From: pgut001@cs.auckland.ac.nz To: martin.rex@sap.com Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for Cc: tls@ietf.org Martin Rex writes: >I spent an hour until I gave up. All implementations of S/Mime-capable >MUAs are so horribly broken that even someone with a technical >understanding runs into brick walls everywhere. It's not just S/MIME clients. The PARC study found that people with *PhDs in computer science* took, on average, over two hours to set up a cert for their own use (using paint-by-numbers screenshots as instructions), rated it as the hardest computer task they'd ever been asked to perform, and had no idea what they'd done to their computer when they were finished. PKI people who reviewed the paper were shocked at this, since they assumed that anyone could do it in a few minutes. (There's lots more like this in the two refs I gave. HCISec is a real eye- opener on the real-world effectiveness of security technology :-). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 28 02:35:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEfsz-0001qU-ST; Sat, 28 Jul 2007 02:34:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEfsy-0001qM-Sb for tls@lists.ietf.org; Sat, 28 Jul 2007 02:34:44 -0400 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEfsw-0004K1-Vr for tls@lists.ietf.org; Sat, 28 Jul 2007 02:34:44 -0400 Received: from oaamta05ps.mx.bigpond.com ([61.9.204.42]) by omta05ps.mx.bigpond.com with ESMTP id <20070728063438.GLHD154.omta05ps.mx.bigpond.com@oaamta05ps.mx.bigpond.com> for ; Sat, 28 Jul 2007 06:34:38 +0000 Received: from saxicola.cuneata.net ([61.9.204.42]) by oaamta05ps.mx.bigpond.com with ESMTP id <20070728063429.KKGN4317.oaamta05ps.mx.bigpond.com@saxicola.cuneata.net> for ; Sat, 28 Jul 2007 06:34:29 +0000 From: Brad Hards To: tls@lists.ietf.org Subject: Re: [TLS] IETF69 TLS WG summary & minutes Date: Sat, 28 Jul 2007 16:36:42 +1000 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707281636.42782.bradh@kdelabs.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Saturday 28 July 2007 00:48, Pasi.Eronen@nokia.com wrote: > The TLS WG summary and preliminary minutes are now > available: > > http://www3.ietf.org/proceedings/07jul/minutes/tls.txt Are there copies of the slides (if any) available? Brad _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 28 17:41:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEu27-0005MA-Cl; Sat, 28 Jul 2007 17:41:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEu26-0005M5-BM for tls@ietf.org; Sat, 28 Jul 2007 17:41:06 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEu26-0004TC-0e for tls@ietf.org; Sat, 28 Jul 2007 17:41:06 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id BEC142F0 for ; Sat, 28 Jul 2007 17:41:27 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 8C09569CFC for ; Sat, 28 Jul 2007 17:41:27 -0400 (EDT) Message-ID: <46ABB82D.8090709@pobox.com> Date: Sat, 28 Jul 2007 14:42:05 -0700 From: Mike User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [TLS] TLS 1.2 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I realize it's still a moving target, but I updated my test server to implement TLS 1.2 as of the latest draft (-04). You can test against it at https://www.mikestoolbox.net Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jul 29 12:56:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFC4G-0007ZS-FI; Sun, 29 Jul 2007 12:56:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFC4E-0007QM-Nl for tls@ietf.org; Sun, 29 Jul 2007 12:56:30 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFC4E-0008Vr-ES for tls@ietf.org; Sun, 29 Jul 2007 12:56:30 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 166672EF for ; Sun, 29 Jul 2007 12:56:52 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id D95636A0FC for ; Sun, 29 Jul 2007 12:56:51 -0400 (EDT) Message-ID: <46ACC722.8080702@pobox.com> Date: Sun, 29 Jul 2007 09:58:10 -0700 From: Mike User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [TLS] RFC 4507bis X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I'm working on adding support for RFC 4507 to my code and have found a few issues with the draft. - Should the NewSessionTicket message be included in the hash used to create/verify the Finished message. I believe it should since it's a handshake message, but it's not stated anywhere. I think it would be a good idea to specifically state that it is. - Is it legal for the server to resume a session and not provide a NewSessionTicket? The message flow I'm referring to would look like this: Client Server ClientHello (SessionTicket extension) --> ServerHello (no SessionTicket extension) [ChangeCipherSpec] <-- Finished [ChangeCipherSpec] Finished --> Application Data <-> Application Data If this is not allowed, it should probably be stated that when a server resumes a session using a SessionTicket, it MUST send an empty Session Ticket extension and a NewSessionTicket message (optionally with an empty ticket). - It may be useful to state that the MAC computation in the ticket is over the encrypted contents to be able to quickly reject a ticket and not have to perform a decryption first. - Should HMAC-SHA256 be recommended instead of HMAC-SHA1? - StatePlaintext needs more data fields when TLS extensions are used such as max fragment length. This should be obvious, but it wouldn't hurt to state. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jul 29 13:20:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFCRg-0004wy-9n; Sun, 29 Jul 2007 13:20:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFCRe-0004wq-3c for tls@ietf.org; Sun, 29 Jul 2007 13:20:42 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFCRb-00010q-LV for tls@ietf.org; Sun, 29 Jul 2007 13:20:39 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 8C0DD2F0 for ; Sun, 29 Jul 2007 13:21:00 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 595DD6A133 for ; Sun, 29 Jul 2007 13:21:00 -0400 (EDT) Message-ID: <46ACCCCB.8000201@pobox.com> Date: Sun, 29 Jul 2007 10:22:19 -0700 From: Mike User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: tls@ietf.org References: <46ABB82D.8090709@pobox.com> In-Reply-To: <46ABB82D.8090709@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [TLS] TLS 1.2 hash agility X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I found an issue with hash agility that I think needs to be addressed. Right now I can claim to support all of the hash functions since my code can handle RSA with SHA-XXX. I also support DSA with SHA-1, and since currently that is the only supported hash function for DSA, I'm OK. The problem will come about when DSA is changed to allow the use of SHA-256, etc. If I were to leave my code as is, it would suddenly be broken since if someone were to try using DSA with SHA- 256, it would fail to create/verify signatures. This means I either need to advertise support for only SHA-1 and MD5, and wait for my encryption library provider to support the new DSA modes, or I can disable all of DSA until my encryption library supports them, which will allow me to support RSA with the better SHA algorithms. Neither of these options is optimal. I think the solution we need is to specifically list each supported signature algorithm, e.g. enum { rsa_with_md5(0), rsa_with_sha1(1), rsa_with_sha256(2), rsa_with_sha384(3), rsa_with_sha512(4), dsa_with_sha1(5), (65535) }; These may not be specific enough, as I've seen suggestions for, e.g. rsa_pkcs1v1_5_with_sha1, and I've heard that some algorithms need parameters, but I think I've made my point. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jul 29 13:40:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFCkW-00073e-Do; Sun, 29 Jul 2007 13:40:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFCkU-00073U-Tz for tls@ietf.org; Sun, 29 Jul 2007 13:40:11 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFCkT-0000xg-Ee for tls@ietf.org; Sun, 29 Jul 2007 13:40:10 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=k/XuzXZNDvQ73bQ1y/cBeMvtlpJZZJJAW58ijOC9AqsfW5UVz/0Axdi6mYR3TwY5; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.49] (helo=elwamui-sweet.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IFCkQ-0002rP-6k; Sun, 29 Jul 2007 13:40:06 -0400 Received: from 64.183.183.188 by webmail.pas.earthlink.net with HTTP; Sun, 29 Jul 2007 13:40:05 -0400 Message-ID: <20230308.1185730806178.JavaMail.root@elwamui-sweet.atl.sa.earthlink.net> Date: Sun, 29 Jul 2007 12:40:05 -0500 (GMT-05:00) From: jwkckid1@ix.netcom.com To: Mike , tls@ietf.org Subject: Re: [TLS] RFC 4507bis Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068865979ef6ee5ba0e8795f69f25cf78584350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.49 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jwkckid1@ix.netcom.com 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: , Errors-To: tls-bounces@lists.ietf.org Mike and all, I would say that HMAC-SHA256 should be recomended. -----Original Message----- >From: Mike >Sent: Jul 29, 2007 11:58 AM >To: tls@ietf.org >Subject: [TLS] RFC 4507bis > >I'm working on adding support for RFC 4507 to my code >and have found a few issues with the draft. > > - Should the NewSessionTicket message be included > in the hash used to create/verify the Finished > message. I believe it should since it's a > handshake message, but it's not stated anywhere. > I think it would be a good idea to specifically > state that it is. > > - Is it legal for the server to resume a session > and not provide a NewSessionTicket? The message > flow I'm referring to would look like this: > > Client Server > ClientHello > (SessionTicket extension) --> > ServerHello > (no SessionTicket extension) > [ChangeCipherSpec] > <-- Finished > [ChangeCipherSpec] > Finished --> > Application Data <-> Application Data > > If this is not allowed, it should probably be > stated that when a server resumes a session using > a SessionTicket, it MUST send an empty Session > Ticket extension and a NewSessionTicket message > (optionally with an empty ticket). > > - It may be useful to state that the MAC computation > in the ticket is over the encrypted contents to > be able to quickly reject a ticket and not have to > perform a decryption first. > > - Should HMAC-SHA256 be recommended instead of > HMAC-SHA1? > > - StatePlaintext needs more data fields when TLS > extensions are used such as max fragment length. > This should be obvious, but it wouldn't hurt to > state. > >Mike > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jul 29 17:05:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFFwc-0001TW-Sv; Sun, 29 Jul 2007 17:04:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFFwb-0001TR-Mg for tls@lists.ietf.org; Sun, 29 Jul 2007 17:04:53 -0400 Received: from ccaix.jsums.edu ([143.132.8.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFFwa-0005U7-CS for tls@lists.ietf.org; Sun, 29 Jul 2007 17:04:53 -0400 Received: from webmail.jsums.edu ([143.132.8.100]) by ccaix.jsums.edu (8.13.1/8.13.1) with ESMTP id l6TL4pWU018257; Sun, 29 Jul 2007 16:04:51 -0500 Received: from 172.134.192.106 (SquirrelMail authenticated user nmeghanathan) by webmail.jsums.edu with HTTP; Sun, 29 Jul 2007 16:04:51 -0500 (CDT) Message-ID: <4654.172.134.192.106.1185743091.squirrel@webmail.jsums.edu> Date: Sun, 29 Jul 2007 16:04:51 -0500 (CDT) From: nmeghanathan@jsums.edu To: tls@lists.ietf.org User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: iaria.announce@gmail.com Subject: [TLS] [ICN 2008] - Call for Papers - The Seventh International Conference on Networking, 2008 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Please apologize for any cross-postings. ====================== Invitation: Please consider to contribute and distribute to the appropriate groups the following CALL FOR PAPERS, TUTORIALS, PANELS ICN 2008, The Seventh International Conference on Networking April 13-18, 2008 - Cancun, Mexico Site: http://www.iaria.org/conferences2008/ICN08.html Submit a paper: http://www.iaria.org/conferences2008/SubmitICN08.html Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be invited for specialized journals. Important deadlines: Submission deadline: November 5, 2007 Notification of acceptance: December 15, 2007 Registration/camera ready: January 20, 2008 ICN 2008 Topics (details in the CfP on site): 1. Communication theory 2. Communications switching and routing 3. Communications modeling 4. Communications security 5. Computer communications 6. Distributed communications 7. Signal processing in communications 8. Multimedia and multicast communications 9. Wireless communications (satellite, WLL, 4G, Ad Hoc, sensor networks) 10. Next generation networks [NGN] principles 11. Storage area networks [SAN] 12. Access and home networks 13. High-speed networks 14. Optical networks 15. Peer-to-peer and overlay networking 16. Mobile networking and systems 17. MPLS-VPN, IPSec-VPN networks 18. GRID networks 19. Broadband networks 20. Quality of service, service level agreement [QoS/SLA] 21. Reliability, availability, serviceability [RAS] 22. Traffic engineering, metering, monitoring 23. Voice over IP services 24. Performance evaluation, tools, simulation 25. Network, control and service architectures 26. Network signaling, pricing and billing 27. Network middleware 28. Telecommunication networks architectures 29. On-demand networks, utility computing architectures 30. Applications and case studies 31. NGN protocol design and evaluation 32. NGN Standard Activities [ITU, TMF, 3GPP, IETF, etc.] 33. NGN Device Instrumentation 34. Network Management, scheduling and policy 35. NGN policy-based control 36. Networks policy-based management 37. Management of autonomic networks and systems ====================== IARIA Publicity Board ====================== _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jul 29 17:11:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFG3M-0005Dd-0c; Sun, 29 Jul 2007 17:11:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFG3K-0005DY-D6 for tls@lists.ietf.org; Sun, 29 Jul 2007 17:11:50 -0400 Received: from ccaix.jsums.edu ([143.132.8.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFG3J-0005as-Vr for tls@lists.ietf.org; Sun, 29 Jul 2007 17:11:50 -0400 Received: from webmail.jsums.edu ([143.132.8.100]) by ccaix.jsums.edu (8.13.1/8.13.1) with ESMTP id l6TLBmL1018947; Sun, 29 Jul 2007 16:11:49 -0500 Received: from 172.134.192.106 (SquirrelMail authenticated user nmeghanathan) by webmail.jsums.edu with HTTP; Sun, 29 Jul 2007 16:11:49 -0500 (CDT) Message-ID: <4700.172.134.192.106.1185743509.squirrel@webmail.jsums.edu> Date: Sun, 29 Jul 2007 16:11:49 -0500 (CDT) From: nmeghanathan@jsums.edu To: tls@lists.ietf.org User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: iaria.announce@gmail.com Subject: [TLS] [ICONS 2008] Call for Papers - The Third International Conference on Systems, 2008 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Please apologize for any cross-postings. ====================== Invitation: Please consider to contribute and distribute to the appropriate groups the following CALL FOR PAPERS, TUTORIALS, PANELS ICONS 2008, The Third International Conference on Systems April 13-18, 2008 - Cancun, Mexico Site: http://www.iaria.org/conferences2008/ICONS08.html Submit a paper: http://www.iaria.org/conferences2008/SubmitICONS08.html Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be invited for specialized journals. Important deadlines: Submission deadline: November 5, 2007 Notification of acceptance: December 15, 2007 Registration/camera ready: January 20, 2008 ICONS 2008 Topics (details in the CfP on site): * Systems' theory and practice * System engineering * Systems' instrumentation * Embedded systems and systems-on-the-chip * Target-oriented systems * Specialized systems * Validation systems * Security and protection systems * Mobile communications and learning * Advanced systems * Application-oriented systems * Safety in industrial systems * Micro and nano structures and systems * Embedded systems * Industrial applications ====================== IARIA Publicity Board ====================== _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jul 29 22:05:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFKdU-0000tQ-W6; Sun, 29 Jul 2007 22:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFKdT-0000q6-8G for tls@lists.ietf.org; Sun, 29 Jul 2007 22:05:27 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFKdR-0003vD-Qa for tls@lists.ietf.org; Sun, 29 Jul 2007 22:05:27 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id DF7263BF1F; Mon, 30 Jul 2007 04:05:24 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14329-02-7; Mon, 30 Jul 2007 04:05:24 +0200 (CEST) Received: from [192.168.1.2] (c80-217-233-219.bredband.comhem.se [80.217.233.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 3651F3BF0A; Mon, 30 Jul 2007 04:05:14 +0200 (CEST) In-Reply-To: <200707281636.42782.bradh@kdelabs.net> References: <200707281636.42782.bradh@kdelabs.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <63751A47-D26F-4F14-B42A-BCBAEF2C31B4@it.su.se> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Subject: Re: [TLS] IETF69 TLS WG summary & minutes Date: Mon, 30 Jul 2007 04:05:12 +0200 To: Brad Hards X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.059 tagged_above=-99 required=7 tests=[AWL=0.253, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org 28 jul 2007 kl. 08.36 skrev Brad Hards: > On Saturday 28 July 2007 00:48, Pasi.Eronen@nokia.com wrote: >> The TLS WG summary and preliminary minutes are now >> available: >> >> http://www3.ietf.org/proceedings/07jul/minutes/tls.txt > Are there copies of the slides (if any) available? https://datatracker.ietf.org/meeting/69/materials.html Go down to the TLS entry. Love _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 30 11:15:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWy2-0008Cr-4y; Mon, 30 Jul 2007 11:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFWy1-0008Ck-0o for tls@ietf.org; Mon, 30 Jul 2007 11:15:29 -0400 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFWxz-0000QB-Ra for tls@ietf.org; Mon, 30 Jul 2007 11:15:28 -0400 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l6UFFPZi004523 for ; Mon, 30 Jul 2007 11:15:25 -0400 (EDT) Received: from 144.51.60.33 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 30 Jul 2007 11:15:25 -0400 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Jul 2007 11:15:25 -0400 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 Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating Date: Mon, 30 Jul 2007 11:15:13 -0400 Message-ID: In-Reply-To: <97106756681A40418FDFFE56@446E7922C82D299DB29D899F> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] the use cases for GSS-based TLS and the plea for integrating Thread-Index: AcfQVRHmAgF77DMERoW29pd7DA248wCW9BQA References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp><48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org><46A8FD4F.7050203@it.su.se> <97106756681A40418FDFFE56@446E7922C82D299DB29D899F> From: "Kemp, David P." To: X-OriginalArrivalTime: 30 Jul 2007 15:15:25.0899 (UTC) FILETIME=[74D291B0:01C7D2BC] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15332000 X-TM-AS-Result: : Yes--12.055700-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwMzIxNS03MDg2?= =?us-ascii?B?NDctNzAxNzQxLTcwMTQ1NS03MDM0ODktNzA2NDcxLTcwMjYwOS03?= =?us-ascii?B?MTAwMTktNzAyMzQyLTcwOTU4NC03MDIxMTMtMTIxNDE0LTcwMDY2?= =?us-ascii?B?Ny0xMjExMjQtNzAxNTc2LTEyMTI1Ny03MDIzNzYtNzA3ODY2LTcw?= =?us-ascii?B?NDQ0NS03MDIxMjYtNzAyNjI2LTcwNDQzMC03MDU4MDItNzAwNzgz?= =?us-ascii?B?LTcwNTg2MS0xMTAwMjQtNzAwOTgyLTcwNTg5MS0zOTAwNzgtNzEw?= =?us-ascii?B?OTcwLTcwNjY5MS03MTE0MDItNzAyMDIwLTcwMDkwMS03MDE0OTkt?= =?us-ascii?B?NzA2NDU0LTcwMjYzOC0xMTMyODQtNzA0MDk2LTcwMjc2Mi0xMzkw?= =?us-ascii?B?MDYtNzAxMjA3LTcwMDA3My03MDAwNzUtMTM5MDEwLTcwNzY2My03?= =?us-ascii?B?MDE2MTgtNzA4NzUyLTcwMDk5NC03MDI3MjYtNzA0OTgwLTcwMTIz?= =?us-ascii?B?Ni03MDAxMDQtNzAxMzg3LTE0ODAzOS0xNDgwNTA=?= X-Spam-Score: -1.0 (-) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org "Today's interim solution to authentication"??? What do you=20 see as the ideal, goal solution to authentication? Dubious qualities related to factory-default trust lists, issuance practices, etc can be addressed by changing practices without changing technologies. If there were a perfect (non-dubious) scheme for establishing Kerberos credentials for all TLS servers on the Internet and configuring clients to trust only "suitable" servers, that same system could be implemented more easily and scaleably using certificates. If the X.500 naming system is considered dubious, certificates could (and IMO should) be issued using names relevant to the application (DNS-based, UPNs, issuer/account, etc) rather than artificially creating ISO Directory names where they are not needed. In short, I see SSO being as over-hyped today as PKI was a decade ago. Every website that requires users to create password accounts today could just as easily issue certificates instead and users would get SSO for free. An Amazon cert, an eBay cert, banking and brokerage account certs, IM, discussion forum and online gaming certs, all unlocked with a single password. TLS supports that today (well, almost - it could be easier to manage your whole wallet of certs on a USB flash drive) but for some reason (perceptions created by the CA industry?) PKI does not. So my question at the top is genuine - what characteristics of today's authentication solutions make them "interim" and dubious, and what characteristics are required of ideal Internet-scale authentication solutions? Dave -----Original Message----- From: Chris Newman [mailto:Chris.Newman@Sun.COM]=20 Leif Johansson wrote on 7/26/07 22:00 +0200: > Would you support a password-based scheme inside TLS or > would you support removing authentication from TLS entierly? No. Server certificate authentication is useful in practice as part of today's=20 interim solution to authentication despite certain dubious qualities. As=20 client certificate authentication is a rarely used feature of TLS, it's=20 questionable whether it should have been included in the original design.=20 However, given that the mechanism has deployed well in implementations and is=20 actually used in some enclaves, it would be far too disruptive to change now.=20 Client certificates are also less problematic because the identity service=20 lookup can be deferred to the application layer using a mechanism such as SASL=20 EXTERNAL or IMAP "* PREAUTH". - Chris _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 30 19:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFeUr-0005VC-4b; Mon, 30 Jul 2007 19:17:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFeUp-0005PA-Bz for tls@ietf.org; Mon, 30 Jul 2007 19:17:51 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFeTq-0005wD-M6 for tls@ietf.org; Mon, 30 Jul 2007 19:17:51 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6UNGoHM019413 for ; Mon, 30 Jul 2007 23:16:50 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JM000H01LDSU100@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for tls@ietf.org; Mon, 30 Jul 2007 17:16:50 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JM000D57LZZUG00@mail-amer.sun.com>; Mon, 30 Jul 2007 17:16:49 -0600 (MDT) Date: Mon, 30 Jul 2007 16:17:39 -0700 From: Chris Newman Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating In-reply-to: To: "Kemp, David P." , tls@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200707171840.l6HIeg9M018099@fs4113.wdf.sap.corp> <48A6320349FD1EDBE937A357@dhcp-26f9.ietf69.org> <46A8FD4F.7050203@it.su.se> <97106756681A40418FDFFE56@446E7922C82D299DB29D899F> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Kemp, David P. wrote on 7/30/07 11:15 -0400: > "Today's interim solution to authentication"??? What do you > see as the ideal, goal solution to authentication? > ... > So my question at the top is genuine - what characteristics > of today's authentication solutions make them "interim" and > dubious, and what characteristics are required of ideal > Internet-scale authentication solutions? This is the wrong forum to discuss authentication technologies in detail. Some of the problems with the presently deployed authentication mechanisms are described in draft-hartman-webauth-phishing-05. - Chris _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls