From tls-bounces@lists.ietf.org Thu Mar 01 14:53:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMrJc-0003jm-0z; Thu, 01 Mar 2007 14:51:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMrJa-0003jY-DX for tls@ietf.org; Thu, 01 Mar 2007 14:51:46 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMrJZ-0001c4-5l for tls@ietf.org; Thu, 01 Mar 2007 14:51:46 -0500 Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l21JpgpC025298 for ; Thu, 1 Mar 2007 13:51:42 -0600 (CST) Received: from hal.lucentradius.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id l21Jpgmv009960 for ; Thu, 1 Mar 2007 13:51:42 -0600 (CST) Received: from [192.168.0.28] (rocinante.lucentradius.com [192.168.0.28]) by hal.lucentradius.com (8.12.9+Sun/8.12.9) with ESMTP id l21Jpf9U009894 for ; Thu, 1 Mar 2007 11:51:41 -0800 (PST) Message-ID: <45E72ECD.9000603@alcatel-lucent.com> Date: Thu, 01 Mar 2007 11:51:41 -0800 From: Jan Nordqvist User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [TLS] Stateless TLS Session Resumption extension and EAP-FAST. 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 apologize if this gets duplicated, I had the wrong address registered: During some recent work incorporating EAP-FAST support into our TLS stack I have discovered that the devices we use for testing are violating the format of the stateless session ticket extension definition per RFC-4507. In all instances I have seen, the whole SessionTicket is preceded by a two-byte 'type' field, i.e. the definition is really struct { uint16 type; opaque ticket<0..2^16-1>; } SessionTicket; I don't know the size of deployments of EAP-FAST devices versus other implementations using the session ticket extension, but it seems that either RFC-4507 needs to be updated to reflect what is actually implemented or perhaps the extension should be split into two. Regards, Jan Nordqvist _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Mar 05 00:45: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 1HO5yH-0007s5-4e; Mon, 05 Mar 2007 00:42:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO5yG-0007rr-1b for tls@ietf.org; Mon, 05 Mar 2007 00:42:52 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO5yE-0002CH-O2 for tls@ietf.org; Mon, 05 Mar 2007 00:42:52 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 3A09C1CC24 for ; Sun, 4 Mar 2007 21:41:58 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Sun, 04 Mar 2007 21:41:58 -0800 From: EKR Message-Id: <20070305054158.3A09C1CC24@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: [TLS] TLS 1.2 draft 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've just submitted a revised draft-ietf-tls-rfc4346bis-03. Until it shows up, you can find a copy at: https://svn.resiprocate.org/rep/ietf-drafts/ekr/tls/tls.txt Here's a list of the major changes in this version. I'll post a list of the few remaining open issues soon. -Ekr [RFC Editor: Please delete this] - Forbid decryption_failed [issue 5] - Fix CertHashTypes declaration [issue 20] - Fix client_version in 7.4.1.2 [issue 19] - Require Bleichenbacher and timing attack protection [issues 17 and 12]. - Merged RFC-editor changes back in. - Editorial changes from NIST [issue 8] - Clarified the meaning of HelloRequest [issue 39] - Editorial nits from Peter Williams [issue 35] - Made maximum fragment size a MUST [issue 9] - Clarified that resumption is not mandatory and servers may refuse [issue 37] - Fixed identifier for cert_hash_types [issue 38] - Forbid sending unknown record types [issue 11] - Clarify that DH parameters and other integers are unsigned [issue 28] - Clarify when a server Certificate is sent [isssue 29] - Prohibit zero-length fragments [issue 10] - Fix reference for DES/3DES [issue 18] - Clean up some notes on deprecated alerts [issue 6] - Remove ephemeral RSA [issue 3] - Stripped out discussion of how to generate the IV and replaced it with a randomness/unpredictability requirement [issue 7] - Replaced the PKCS#1 text with references to PKCS#1 v2. This also includes DigestInfo encoding [issues 1 and 22] - Removed extension definitions and merged the ExtendedHello definitions [issues 31 and 32] - Replaced CipherSpec references with SecurityParameters references [issue 2] - Cleaned up IANA text [issues 33 and 34] - Cleaned up backward compatibility text [issue 25] _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Mar 05 17:19: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 1HOLVi-0004q2-23; Mon, 05 Mar 2007 17:18:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOLVg-0004pC-91 for tls@ietf.org; Mon, 05 Mar 2007 17:18:24 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOLVd-00065j-T1 for tls@ietf.org; Mon, 05 Mar 2007 17:18:24 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 05 Mar 2007 14:18:21 -0800 X-IronPort-AV: i="4.14,251,1170662400"; d="scan'208"; a="45411909:sNHT49577454" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l25MILcU021717; Mon, 5 Mar 2007 14:18:21 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l25MIJYU021561; Mon, 5 Mar 2007 22:18:21 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 14:18:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Stateless TLS Session Resumption extension and EAP-FAST. Date: Mon, 5 Mar 2007 14:18:19 -0800 Message-ID: In-Reply-To: <45E72ECD.9000603@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Stateless TLS Session Resumption extension and EAP-FAST. Thread-Index: AcdcO18dYchwt6jARjGQj1RE7JzOdgDN6srA From: "Joseph Salowey \(jsalowey\)" To: "Jan Nordqvist" , X-OriginalArrivalTime: 05 Mar 2007 22:18:20.0536 (UTC) FILETIME=[2E8FA780:01C75F74] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2082; t=1173133101; x=1173997101; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[TLS]=20Stateless=20TLS=20Session=20Resumption=20exte nsion=20and=20EAP-FAST. |Sender:=20; bh=Qggd7ZABo0GN9KtZTbzSRRDoPWNs9e+ON3Puf8EQE9k=; b=BwXNXsSsiqjOXLUDVtcHvHNonjUe9nFdhxUlll6BeDBdR78HLcQyrbYWo9thMrNvotdsr2vS haD5POTqnSBVdn1lLLqiYDtdwTY6JIZUB80yTpl/Ea8zyhyucJoP/piZ; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Jan, You are correct, there is an issue with current implementation. Thanks for pointing this out. Details follow: Current EAP-FAST implementations do not format the extension correctly as to spec. They leave out one of the length fields. EAP-FAST implementation: struct { uint16 extensionType =09 opaque ticket<0..2^16-1> } SessionTicketExtension Example encoding: 00 23 LL LL TT TT TT ... LL - ticket length TT - ticket RFC4507: > struct { > opaque ticket<0..2^16-1>; > } SessionTicket; > > struct { > uint16 extensionType =09 > opaque SessionTicket<0..2^16-1> > } SessionTicketExtension > Example encoding: 00 23 LN LN LL LL TT TT TT.... LN - length of ticket + 2-bytes Joe=20 > -----Original Message----- > From: Jan Nordqvist [mailto:jnordqvist@alcatel-lucent.com]=20 > Sent: Thursday, March 01, 2007 11:52 AM > To: tls@ietf.org > Subject: [TLS] Stateless TLS Session Resumption extension and=20 > EAP-FAST. >=20 > I apologize if this gets duplicated, I had the wrong address=20 > registered: >=20 > During some recent work incorporating EAP-FAST support into=20 > our TLS stack I have discovered that the devices we use for=20 > testing are violating the format of the stateless session=20 > ticket extension definition per RFC-4507. In all instances I=20 > have seen, the whole SessionTicket is preceded by a two-byte=20 > 'type' field, i.e. the definition is really >=20 > struct { > uint16 type; > opaque ticket<0..2^16-1>; > } SessionTicket; >=20 > I don't know the size of deployments of EAP-FAST devices=20 > versus other implementations using the session ticket=20 > extension, but it seems that either RFC-4507 needs to be=20 > updated to reflect what is actually implemented or perhaps=20 > the extension should be split into two. >=20 > Regards, > Jan Nordqvist >=20 >=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 Mar 05 20:24: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 1HOOOd-0007ac-SR; Mon, 05 Mar 2007 20:23:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOOOc-0007aW-Pe for tls@ietf.org; Mon, 05 Mar 2007 20:23:18 -0500 Received: from smtpout1463.sc1.he.tucows.com ([64.97.157.163] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOOOb-0004DS-Fh for tls@ietf.org; Mon, 05 Mar 2007 20:23:18 -0500 Received: from [192.168.0.5] (67.188.127.211) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 45B8E5A0008A166D; Tue, 6 Mar 2007 01:23:09 +0000 Message-ID: <45ECC270.4090706@bolyard.com> Date: Mon, 05 Mar 2007 17:22:56 -0800 From: Nelson B Bolyard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070227 SeaMonkey/1.5a MIME-Version: 1.0 To: EKR Subject: Re: [TLS] TLS 1.2 draft References: <20070305054158.3A09C1CC24@delta.rtfm.com> In-Reply-To: <20070305054158.3A09C1CC24@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 EKR wrote: > I've just submitted a revised draft-ietf-tls-rfc4346bis-03. > > Until it shows up, you can find a copy at: > https://svn.resiprocate.org/rep/ietf-drafts/ekr/tls/tls.txt > > Here's a list of the major changes in this version. I'll > post a list of the few remaining open issues soon. > > -Ekr Eric, Where can one find the numbered list of issues to which your comments refer? Also, the server of the URL you gave above seems to hang after delivering the first 5.5 pages of the draft. I have tried it repeatedly with the same results each time. I hope it can & will be fixed. Regards, /Nelson Bolyard > - Forbid decryption_failed [issue 5] > - Fix CertHashTypes declaration [issue 20] > - Fix client_version in 7.4.1.2 [issue 19] > - Require Bleichenbacher and timing attack protection [issues 17 > and 12]. > - Merged RFC-editor changes back in. > - Editorial changes from NIST [issue 8] > - Clarified the meaning of HelloRequest [issue 39] > - Editorial nits from Peter Williams [issue 35] > - Made maximum fragment size a MUST [issue 9] > - Clarified that resumption is not mandatory and servers may > refuse [issue 37] > - Fixed identifier for cert_hash_types [issue 38] > - Forbid sending unknown record types [issue 11] > - Clarify that DH parameters and other integers are unsigned [issue 28] > - Clarify when a server Certificate is sent [isssue 29] > - Prohibit zero-length fragments [issue 10] > - Fix reference for DES/3DES [issue 18] > - Clean up some notes on deprecated alerts [issue 6] > - Remove ephemeral RSA [issue 3] > - Stripped out discussion of how to generate the IV and replaced it > with a randomness/unpredictability requirement [issue 7] > - Replaced the PKCS#1 text with references to PKCS#1 v2. This also > includes DigestInfo encoding [issues 1 and 22] > - Removed extension definitions and merged the ExtendedHello > definitions [issues 31 and 32] > - Replaced CipherSpec references with SecurityParameters references > [issue 2] > - Cleaned up IANA text [issues 33 and 34] > - Cleaned up backward compatibility text [issue 25] _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Mar 05 20:30: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 1HOOV2-0004UK-9r; Mon, 05 Mar 2007 20:29:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOOV1-0004U9-8A for tls@ietf.org; Mon, 05 Mar 2007 20:29:55 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOOUz-0005NP-UK for tls@ietf.org; Mon, 05 Mar 2007 20:29:55 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 1EDA01CC32; Mon, 5 Mar 2007 17:29:02 -0800 (PST) To: Nelson B Bolyard Subject: Re: [TLS] TLS 1.2 draft References: <20070305054158.3A09C1CC24@delta.rtfm.com> <45ECC270.4090706@bolyard.com> From: EKR Date: Mon, 05 Mar 2007 17:29:01 -0800 In-Reply-To: <45ECC270.4090706@bolyard.com> (Nelson B. Bolyard's message of "Mon, 05 Mar 2007 17:22:56 -0800") Message-ID: <861wk340te.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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 Nelson B Bolyard writes: > EKR wrote: >> I've just submitted a revised draft-ietf-tls-rfc4346bis-03. >> >> Until it shows up, you can find a copy at: >> https://svn.resiprocate.org/rep/ietf-drafts/ekr/tls/tls.txt >> >> Here's a list of the major changes in this version. I'll >> post a list of the few remaining open issues soon. >> >> -Ekr > > Eric, > > Where can one find the numbered list of issues to which your comments refer? Pasi has created a tracker at: http://www1.tools.ietf.org/wg/tls/trac/ If there's an issue you think should be on here but isn't, please post to the list. [I'll be starting a discussion about alert mandatoriness in response to one of NISTs issues and the one you raised shortly.] > Also, the server of the URL you gave above seems to hang after delivering > the first 5.5 pages of the draft. I have tried it repeatedly with the > same results each time. I hope it can & will be fixed. Me too, but I don't control it, since it's a resiprocate svn repository I just leech off of. Presumably the draft will be up on the IETF site in the not too distant future. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Mar 05 20:49: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 1HOOnY-0006Uy-Ij; Mon, 05 Mar 2007 20:49:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOOnX-0006Ut-D4 for tls@ietf.org; Mon, 05 Mar 2007 20:49:03 -0500 Received: from smtpout1474.sc1.he.tucows.com ([64.97.157.174] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOOnW-0007b3-3b for tls@ietf.org; Mon, 05 Mar 2007 20:49:03 -0500 Received: from [192.168.0.5] (67.188.127.211) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 45B8E5A0008A21A7 for tls@ietf.org; Tue, 6 Mar 2007 01:48:59 +0000 Message-ID: <45ECC887.2070307@bolyard.com> Date: Mon, 05 Mar 2007 17:48:55 -0800 From: Nelson B Bolyard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070227 SeaMonkey/1.5a MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] TLS 1.2 draft References: <20070305054158.3A09C1CC24@delta.rtfm.com> <45ECC270.4090706@bolyard.com> <861wk340te.fsf@delta.rtfm.com> In-Reply-To: <861wk340te.fsf@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 EKR wrote: > Nelson B Bolyard writes: >> EKR wrote: >>> I've just submitted a revised draft-ietf-tls-rfc4346bis-03. >>> >>> Until it shows up, you can find a copy at: >>> https://svn.resiprocate.org/rep/ietf-drafts/ekr/tls/tls.txt >>> >>> Here's a list of the major changes in this version. I'll >>> post a list of the few remaining open issues soon. >> Where can one find the numbered list of issues to which your comments refer? > > Pasi has created a tracker at: > > http://www1.tools.ietf.org/wg/tls/trac/ > > If there's an issue you think should be on here but isn't, please > post to the list. [I'll be starting a discussion about alert mandatoriness > in response to one of NISTs issues and the one you raised shortly.] Thanks, Eric, This URL gives me the full list in ascending numeric order: _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 03:43: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 1HOVFF-0006Uu-LW; Tue, 06 Mar 2007 03:42:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOVFE-0006Up-C7 for tls@ietf.org; Tue, 06 Mar 2007 03:42:04 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOVFC-0007cy-Uz for tls@ietf.org; Tue, 06 Mar 2007 03:42:04 -0500 Received: from extundo.com (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l268fTss031900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 09:41:30 +0100 From: Simon Josefsson To: EKR References: <20070305054158.3A09C1CC24@delta.rtfm.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070306:tls@ietf.org::LSqSpwkA6CiGzF2m:IoeE X-Hashcash: 1:22:070306:ekr@networkresonance.com::85AwRqpQ92e0vNfV:Pycd Date: Tue, 06 Mar 2007 09:41:29 +0100 In-Reply-To: <20070305054158.3A09C1CC24@delta.rtfm.com> (ekr@networkresonance.com's message of "Sun\, 04 Mar 2007 21\:41\:58 -0800") Message-ID: <87zm6qydae.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,BAYES_00 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.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tls@ietf.org Subject: [TLS] Re: TLS 1.2 draft 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 EKR writes: > - Replaced the PKCS#1 text with references to PKCS#1 v2. This also > includes DigestInfo encoding [issues 1 and 22] The new text is: In RSA signing, the opaque vector contains the signature generated using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1B]. As discussed in [PKCS1B], the DigestInfo MUST be DER encoded and for digest algorithms without parameters (which include SHA-1) the DigestInfo.AlgorithmIdentifier.parameters field SHOULD be omitted but implementations MUST accept both without parameters and with NULL parameters. Note that earlier versions of TLS used a different RSA signature scheme which did not include a DigestInfo encoding. The PKCS#1 v2.1 with erratas, RFC 3447 and IEEE 1363a-2004 includes hash identifier for SHA-1 that corresponds to a present NULL parameter: SHA-1: (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H. Right now, GnuTLS generates NULL and only accepts NULL values. Mike's server generate NULL, and if I remember correctly, it was based on OpenSSL. I am not aware of any other TLS 1.2 servers or clients that are available for testing. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 06:03: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 1HOXQT-0004eh-Ii; Tue, 06 Mar 2007 06:01:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOXQR-0004eR-7n for tls@ietf.org; Tue, 06 Mar 2007 06:01:47 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOXQP-00018L-Ne for tls@ietf.org; Tue, 06 Mar 2007 06:01:47 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l26B1g0G027982 for ; Tue, 6 Mar 2007 13:01:43 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 13:01:32 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 13:01:32 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Mar 2007 13:01:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS 1.2 and hash agility for signatures Thread-Index: Acdf3tLGYRCEwfjbQX+4t6pG0icFRA== From: To: X-OriginalArrivalTime: 06 Mar 2007 11:01:32.0568 (UTC) FILETIME=[CCBD3980:01C75FDE] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070306130143-63213BB0-3EAC7AC9/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: [TLS] TLS 1.2 and hash agility for signatures 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 There's one area in TLS 1.2 that still doesn't give me a warm=20 fuzzy feeling that "yes, this is the way it should be done", and=20 that's the algorithm agility for signatures (in certificates and ClientKeyExchange/ServerKeyExchange messages). I'd like to get some more discussion about this, and fresh ideas on what's the best way to implement it in TLS 1.2. Some issues that don't yet seem right: 1) Asymmetry: The server sends its list of supported hashes in the CertificateRequest message, together with list of trusted CAs (DNs) and ClientCertificateTypes. The client sends the list of supported hashes in cert_hash_types extension, list of trusted CAs (DNs or hashes) in trusted_ca_keys extension, and there's no equivalent of ClientCertificateType. In addition, we have the "cert_type" extension for non-X.509 certs (draft-ietf-tls-openpgp-keys). To make things worse, ClientCertificateTypes field seems quite redundant, since at this point we already know the ciphersuite, and that limits our choice (it doesn't make sense to request dss_sign certificate if you've already negotiated RSA ciphersuite). Or if it's not redundant, then we need more text in the spec explaining why not. Perhaps we can't avoid this asymmetry completely, but is there any way to make this a bit nicer? Perhaps remove the ClientCertificateTypes field in TLS 1.2, and use cert_hash_types extension also from server to client? 2) Wrong concept: instead of telling what hash algorithms we support we'd really like to tell what kinds of signatures we can verify. E.g. for RSA, we have at least three different schemes (PKCS#1 v1.5, PSS and ANSI X9.32), all of which can be used with different hashes. And we also have DSS and ECDSA. For TLS level signatures (ServerKeyExchange/CertificateVerify), some part of this is already determined by the ciphersuite's key exchange algorithm (e.g. RSA here means PKCS#1 v1.5; if someone wants to use RSA PSS we'd define new ciphersuites). But for certificates, the situation is not the same; we could have certificate containing RSA public key signed with DSS, or something. Should we have signature_schemes extension instead of cert_hash_types? (with values like rsa_pkcs15_sha256, dss_sha1, ecdsa_sha512, etc.) =20 Or separate lists for certificate signatures and signatures in TLS? 3) Tying algorithm in ServerKeyExchange/CertificateVerify and certificate. The current spec says that for RSA, signatures in TLS (ServerKeyExchange and CertificateVerify) use the same hash as was used by the CA in the certificate. The idea itself is not wrong: if you're worried about using SHA-1, then it's much more important to use something better in certificates (usually long-lived) than in ServerKeyExchange/CertificateVerify (which include fresh nonces, and are verified only once immediately following signature generation -- so offline attacks don't count). However... what if the cert isn't signed with RSA? Or it's signed with RSA PSS? And is it OK to require the peer to parse its own certificate (something not previously required)? Perhaps we should decouple these? 4) RSA-specific text. It looks like much of the text (and whole cert_hash_types) is really specific to RSA ciphersuites, since the spec fixes SHA-1 for DSS, and RFC4492 specifies that for ECDSA, the hash is always SHA-1 unless otherwise specified by yet-unspecified extension in the certificate. It may not be possible to avoid RSA-specific text, but then it should be easy to see what parts are specific to RSA and what are not. And we should probably plan for hash agility in DSS as well? Comments? I think we'd want something reasonably simple in the spec, but on the other hand, it should be technically coherent as well. I'm planning to sketch something before Prague, but any kinds of ideas (or alternative ways of looking at the problem) would be welcome... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 07:13:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOYWZ-0001bB-DT; Tue, 06 Mar 2007 07:12:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOYWY-0001b4-0a for tls@ietf.org; Tue, 06 Mar 2007 07:12:10 -0500 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 1HOYWW-00005r-63 for tls@ietf.org; Tue, 06 Mar 2007 07:12:09 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l26CC3nB009229 for ; Tue, 6 Mar 2007 14:12:05 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 14:11:55 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 14:11:55 +0200 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] TLS 1.2 draft (issue #25 about SSLv2 Hello) Date: Tue, 6 Mar 2007 14:11:48 +0200 Message-ID: In-Reply-To: <20070305054158.3A09C1CC24@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS 1.2 draft (issue #25 about SSLv2 Hello) Thread-Index: Acde6aPXa9gfhM4rSYiB8Xy/ZQde+QA/bFUQ References: <20070305054158.3A09C1CC24@delta.rtfm.com> From: To: X-OriginalArrivalTime: 06 Mar 2007 12:11:55.0663 (UTC) FILETIME=[A1E661F0:01C75FE8] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070306141205-232F0BB0-3EAB7CD5/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 > Cleaned up backward compatibility text [issue 25] This text (in E.2) still needs some cleaning. Currently it says: challenge_length The length in bytes of the client's challenge to the server to authenticate itself. Historically, permissible values are between 16 and 32 bytes inclusive. When using the SSLv2 backward compatible handshake the client MUST use a 32-byte challenge. [...] challenge Corresponds to ClientHello.random. If the challenge length is less than 32, the TLS server will pad the data with leading (note: not trailing) zero bytes to make it 32 bytes long. Which is not exactly consistent: if the challenge length MUST be 32 bytes, it can't be less than 32 bytes. It was also noted that for historical and/or compatibility reasons, many existing browsers (e.g. Opera, IE6, FireFox 1.5) use 16-byte challenges: http://www1.ietf.org/mail-archive/web/tls/current/msg00985.html My proposal (in the mail linked above) was to to change this to "The length of the challenge field in bytes; MUST be between 16 and 32 (inclusive)." Comments? (At the very least, the text needs to be internally consistent. Preferably it should also promote real-world interoperability and reflect what implementations are expected to do.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 07:41: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 1HOYyA-0002M4-WA; Tue, 06 Mar 2007 07:40:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOYy9-0002Ll-6S for tls@ietf.org; Tue, 06 Mar 2007 07:40:41 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOYy7-0003ML-Ko for tls@ietf.org; Tue, 06 Mar 2007 07:40:41 -0500 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 l26CeV0L001151 for ; Tue, 6 Mar 2007 14:40:35 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 14:40:25 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 14:40:25 +0200 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] sending error alerts: MUST? SHOULD? MAY? Date: Tue, 6 Mar 2007 14:40:15 +0200 Message-ID: In-Reply-To: <20070209224143.C1D075C01E@laser.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] sending error alerts: MUST? SHOULD? MAY? Thread-Index: AcdMmunP/49aCCXEQv+kOELVPvpRrATUK3Lw References: Your message of "Sun, 31 Dec 2006 15:13:24 PST."<45984414.2090209@bolyard.com> <20070209224143.C1D075C01E@laser.networkresonance.com> From: To: X-OriginalArrivalTime: 06 Mar 2007 12:40:25.0400 (UTC) FILETIME=[9CFB8B80:01C75FEC] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070306144035-0334EBB0-4C1B5ED3/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: >=20 > My concern, as I think I mentioned to you privately, is that we not > mandate behaviors that potentially leak security relevant information. > We've had one such situation before with CBC padding. Ultimately, > we really need a review of the security implications of every kind > of error, but not having that I'm reluctant to require behaviors > that haven't been vetted. >=20 > The bottom line, then, is that I'd prefer not to change this language > without explicit security analysis for each change. (Replying to a somewhat old message...) I think a general guideline would be that if you haven't used anything secret yet (the RSA/DH/DSS private key, or any session keys), sending an alert can't leak that secret. The problems we've had have all been associated with revealing errors in processing involving a secret (RSA errors, CBC padding, etc.). So some of the alerts (e.g. those sent by server in response to ClientHello) should be safe, and I do agree with earlier concerns that the spec should be more clear about when they're used. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 09: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 1HOaW7-00020H-9U; Tue, 06 Mar 2007 09:19:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOaW5-00020B-5F for tls@ietf.org; Tue, 06 Mar 2007 09:19:49 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOaW3-0003QG-SY for tls@ietf.org; Tue, 06 Mar 2007 09:19:49 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 50DBEC37B2 for ; Tue, 6 Mar 2007 09:20:09 -0500 (EST) 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 rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 18FB5C37B1 for ; Tue, 6 Mar 2007 09:20:08 -0500 (EST) Message-ID: <45ED78DC.1010805@pobox.com> Date: Tue, 06 Mar 2007 06:21:16 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] TLS 1.2 draft (issue #25 about SSLv2 Hello) References: <20070305054158.3A09C1CC24@delta.rtfm.com> 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: a7d6aff76b15f3f56fcb94490e1052e4 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 could say that the random length MUST be between 16 and 32 bytes, and add that it SHOULD be 32 bytes. Mike Pasi.Eronen@nokia.com wrote: >> Cleaned up backward compatibility text [issue 25] > > This text (in E.2) still needs some cleaning. Currently > it says: > > challenge_length > The length in bytes of the client's challenge to the server to > authenticate itself. Historically, permissible values are between > 16 and 32 bytes inclusive. When using the SSLv2 backward > compatible handshake the client MUST use a 32-byte challenge. > [...] > challenge > Corresponds to ClientHello.random. If the challenge length is > less than 32, the TLS server will pad the data with leading > (note: not trailing) zero bytes to make it 32 bytes long. > > Which is not exactly consistent: if the challenge length MUST be 32 > bytes, it can't be less than 32 bytes. > > It was also noted that for historical and/or compatibility reasons, > many existing browsers (e.g. Opera, IE6, FireFox 1.5) use 16-byte > challenges: > > http://www1.ietf.org/mail-archive/web/tls/current/msg00985.html > > My proposal (in the mail linked above) was to to change this to "The > length of the challenge field in bytes; MUST be between 16 and 32 > (inclusive)." > > Comments? (At the very least, the text needs to be internally > consistent. Preferably it should also promote real-world > interoperability and reflect what implementations are expected to do.) > > Best regards, > Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 09:31: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 1HOag7-0004Yk-Ps; Tue, 06 Mar 2007 09:30:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOag6-0004Yb-3i for tls@ietf.org; Tue, 06 Mar 2007 09:30:10 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOag5-0007J5-2o for tls@ietf.org; Tue, 06 Mar 2007 09:30:09 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1HOafy1Trx-0000Hq; Tue, 06 Mar 2007 15:30:02 +0100 Received: by tau.invalid (Postfix, from userid 1000) id C0D7C1B323; Tue, 6 Mar 2007 15:30:01 +0100 (CET) Date: Tue, 6 Mar 2007 15:30:01 +0100 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] TLS 1.2 and hash agility for signatures Message-ID: <20070306143001.GA19204@tau.invalid> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Provags-ID2: V01U2FsdGVkX1+pTkZJPpAP/mb6SEldaJg62Kmg6ysXvM04Rls GdPJT0mYAivVNgknPfjRUnEaxFGXErrW6FaEsx6qqkRiaGzk+o gZgJ7ee0E8JJhSnzs5seQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 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, Mar 06, 2007 at 01:01:42PM +0200, Pasi.Eronen@nokia.com wrote: > There's one area in TLS 1.2 that still doesn't give me a warm > fuzzy feeling that "yes, this is the way it should be done", and > that's the algorithm agility for signatures (in certificates and > ClientKeyExchange/ServerKeyExchange messages). > > I'd like to get some more discussion about this, and fresh > ideas on what's the best way to implement it in TLS 1.2. > > Some issues that don't yet seem right: > > > 1) Asymmetry: The server sends its list of supported hashes in the > CertificateRequest message, together with list of trusted CAs (DNs) > and ClientCertificateTypes. The client sends the list of supported > hashes in cert_hash_types extension, list of trusted CAs (DNs or > hashes) in trusted_ca_keys extension, and there's no equivalent of > ClientCertificateType. In addition, we have the "cert_type" extension > for non-X.509 certs (draft-ietf-tls-openpgp-keys). > > To make things worse, ClientCertificateTypes field seems quite > redundant, since at this point we already know the ciphersuite, and > that limits our choice (it doesn't make sense to request dss_sign > certificate if you've already negotiated RSA ciphersuite). Or if it's > not redundant, then we need more text in the spec explaining why not. I don't think that there's anything wrong with using a DSA certificate in an RSA ciphersuite. The only cases where symmetry is required are the fixed_dh certificate types (and, similarly, the fixed_ecdh certificate types from RFC 4492), since in these the client certificate is tied to the actual key exchange and client authentication does not use the separate CertificateVerify message. If both the client and the server support all of RSA and DSA and ECDSA, then it might just happen to be the case that the server has an RSA certificate, say, while the client has an ECDSA certificate. So you might see an RSA ciphersuite in the handshake, but the client would still use ECDSA in the CertificateVerify. (This scenario can make quite a lot of sense in certain configurations: RSA signature verification and RSA encryption are usually very easy to do for the client, but ECDSA signing might be much faster than RSA signing.) So it's quite useful if the server can indicate to the client what kinds of signatures it can verify. > Perhaps we can't avoid this asymmetry completely, but is there any way > to make this a bit nicer? Perhaps remove the ClientCertificateTypes > field in TLS 1.2, and use cert_hash_types extension also from server > to client? > > > 2) Wrong concept: instead of telling what hash algorithms we support > we'd really like to tell what kinds of signatures we can verify. > E.g. for RSA, we have at least three different schemes (PKCS#1 v1.5, > PSS and ANSI X9.32), all of which can be used with different hashes. > And we also have DSS and ECDSA. > > For TLS level signatures (ServerKeyExchange/CertificateVerify), some > part of this is already determined by the ciphersuite's key exchange > algorithm (e.g. RSA here means PKCS#1 v1.5; if someone wants to use > RSA PSS we'd define new ciphersuites). But for certificates, the > situation is not the same; we could have certificate containing RSA > public key signed with DSS, or something. > > Should we have signature_schemes extension instead of cert_hash_types? > (with values like rsa_pkcs15_sha256, dss_sha1, ecdsa_sha512, etc.) > Or separate lists for certificate signatures and signatures in TLS? I don't think that there's anything basically wrong with using ClientCertificateType. The list of ClientCertificateType values alone doesn't provide complete information since RSA might mean RSA PKCS#1 v1.5 with a limited selection of hash algorithms only, or might allow much more flexibility. Adding a list of HashType values, as you point out, doesn't quite address this issue since there are more aspects that can be varied than just the choice of hash algorithm. (Also, sometimes, different choices of hash algorithms might be available with different signature algorithms.) Also often (but not always) it's the complete certificate chain that must be considered, i.e. not just the CertificateVerify signature but additionally each and every signature in the client's certificate chain up to some anchor that the server is willing to rely on for verification purposes. (Sometimes the server might not need to validate the actual certificate chain, if permissible client certificates have been made available for direct verification without the computational overhead of a PKI.) So things can be quite complicated. I don't think, though, that we really have to solve all of this in the TLS specification! In practice, the most important part of the CertificateRequest message is certificate_authorities, the list of distinguished names of acceptable CAs. If the client happens to pick a certificate using a chain for which the server does not have an appropriate anchor, then it does not matter at all if the server can handle the hash algorithm (or even the signature algorithm) used by the client for the CertificateVerify or not -- either way the server won't be able to use the signature. But if the client has a certificate signed by a CA that the server is willing to rely on, then generally that CA's policies will determine what signature algorithms (with what hash algortihms, etc.) can be encountered in certificate chains. This is usually enough since, for obvious pragmatic reasons, CAs don't tend to mix lots of different techniques in their certificate chains. (It's similar for the use of the signing key in the client's end-entity certificate -- for the case of RSA, the TLS 1.2 draft quite reasonably, yet somewhat problematically [see below], says that "the same function (denoted Hash) must be used as was used to create the signature for the client's certificate".) So we could spend a lot of time on coming up with a detailed solutions allowing a find-grained negotiation of signing algorithm details, but I think we don't really have to do that. Reality always could be more complicated than what we foresee (a complete solution would, for example, have to provide the server with means to specify the X.509 extensions that it can parse, lest the client use a certificate chain that has to be rejected due to an unknown critical extension). In practice, a rather simple solution should work very well. The list of ClientCertificateType values in the CertificateRequest may be a useful hint. Besides, it is very brief, and we've always had this in the protocol; so there's no reason to throw this out. Maybe adding a list of HashType values (as the TLS 1.2 draft does) is reasonable too, but I don't really see compelling reasons to do so. An optional TLS extension mirroring the client's Cert Hash Types extension would look quite appropriate to me (why use a different tool for server-to-client communcation than for client-to-server communication?) -- also to be interpreted as a hint, not a complete specification of what the server can handle. I don't really think we need signature_schemes in place of cert_hash_types. The rsa_sign client certificate type currently is restricted to RSA PKCS#1 v1.5 signatures, and if there was demand to use PSS, say, a separate client certificate type for RSA-PSS would be reasonable. But then in practice, a demand for PSS would probably mean separate PKIs with end-entity certificates intended for PSS signing anyway (it would be rather silly to use a single RSA key both for PKCS#1 v1.5 and PSS signing), so maybe we shouldn't worry about this too much. > 3) Tying algorithm in ServerKeyExchange/CertificateVerify and > certificate. The current spec says that for RSA, signatures in TLS > (ServerKeyExchange and CertificateVerify) use the same hash as was > used by the CA in the certificate. > > The idea itself is not wrong: if you're worried about using SHA-1, > then it's much more important to use something better in certificates > (usually long-lived) than in ServerKeyExchange/CertificateVerify > (which include fresh nonces, and are verified only once immediately > following signature generation -- so offline attacks don't count). > > However... what if the cert isn't signed with RSA? Or it's signed with > RSA PSS? And is it OK to require the peer to parse its own certificate > (something not previously required)? Perhaps we should decouple these? Well, the client wouldn't really have to actively parse its own certificate, just know what's in there. That's additional data, just like the secret key matching the certificate's public key is additional data. Arguably, the TLS specification should not make such strict rules for the hash algorithm to be used during signing, though, because it's very reasonable to assume that the client's end-entity certificate would completely specify the client's signing algorithm, including the hash algorithm to be used. And this might not match the hash algorithm used by the CA while signing the respective certificate, so the rule in the TLS 1.2 draft might be incompatible with keys that otherwise would be absolutely acceptable for use. (E.g., the CA might have a 4096-bit RSA key and use a 256-bit hash for certificates, but issue certificates on 2048-bit keys intended for use with 224-bit hashes.) The algorithm given in SubjectPublicKey might be more explicit than just an unspecific "rsaEncryption" and might fix the hash algorithm; and even if the SubjectPublicKey does not reveal it, the hash algorithm might be fixed. > 4) RSA-specific text. It looks like much of the text (and whole > cert_hash_types) is really specific to RSA ciphersuites, since the > spec fixes SHA-1 for DSS, and RFC4492 specifies that for ECDSA, the > hash is always SHA-1 unless otherwise specified by yet-unspecified > extension in the certificate. > > It may not be possible to avoid RSA-specific text, but then it should > be easy to see what parts are specific to RSA and what are not. And we > should probably plan for hash agility in DSS as well? Yes, limiting DSA to SHA-1 quite obviously has historic reasons -- or qrather, reasons that hopefully *will* become historic soon when FIPS 186-3 (with support for the newer SHA variants) finally is released! > Comments? I think we'd want something reasonably simple in the spec, > but on the other hand, it should be technically coherent as well. > I'm planning to sketch something before Prague, but any kinds > of ideas (or alternative ways of looking at the problem) would > be welcome... My take is that it is very reasonable to describe quite many things as "SHOULD"s only, since the ability to verify certificates depends on PKIs and their policies anyway, and much of the responsibility can be put there. If a CA is willing to sign certificates that are hard to verify and if a server is willing to accept a PKI relying on such a CA, then why not let them do this? Generally, this won't happen, since CAs will take care to issue certificates that work well in the intended environment. We don't have to freeze all the details of this in the TLS specification. Probably the TLS 1.2 specification should say more about how the individual methods for ClientVerify work, e.g., that rsa_sign strictly means RSASSA-PKCS1-v1_5, or possibly that RSASSA-PKCS1-v1_5 is what SHOULD be used for rsa_sign. I think we should keep ClientCertificateTypes in the CertificateRequest, but maybe remove the HashType list from the CertificateRequest and instead offer a server hello extension for this. (There's a similar client hello extension, so this would provide more consistency within the protocol.) Fixing the hash to SHA-1 for DSA is bad. (As an aside, indeed there are some cases where the new TLS 1.2 draft correctly says "DSA" instead of the incorrect "DSS" -- maybe this finally should be corrected throughout the document; i.e., merely mention the "DSS" terminology in a historical note.) This SHA-1-only approach won't work well when FIPS 186-3 is released, so we should prepare something for the new SHAs. (This affects both the ServerKeyExchange and the CertificateVerify messages.) Similarly, the rule that ties the hash used for RSA signing to the hash used for the respective certificate's signature is problematic. In both cases (ServerKeyExchange and CertificateVerify), the "Cert Hash Types" extension could be turned into a more general "Signature Hash Types" extension (both as a client-side extension and a server-side extension) that also covers the signatures within TLS, not just those appearing in certificates. The "rsa" and "dsa" cases of the Signature type probably should be equipped with HashType fields so that signatures can be verified without having to guess! Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 10:22: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 1HObTI-0001NT-SL; Tue, 06 Mar 2007 10:21:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HObTI-0001NO-7m for tls@ietf.org; Tue, 06 Mar 2007 10:21:00 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HObTF-00051v-T8 for tls@ietf.org; Tue, 06 Mar 2007 10:21:00 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id A2C221CC35; Tue, 6 Mar 2007 07:20:06 -0800 (PST) To: Subject: Re: [TLS] TLS 1.2 draft (issue #25 about SSLv2 Hello) References: <20070305054158.3A09C1CC24@delta.rtfm.com> From: EKR Date: Tue, 06 Mar 2007 07:20:06 -0800 In-Reply-To: (Pasi Eronen's message of "Tue, 6 Mar 2007 14:11:48 +0200") Message-ID: <86mz2q2yc9.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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 writes: >> Cleaned up backward compatibility text [issue 25] > > This text (in E.2) still needs some cleaning. Currently > it says: > > challenge_length > The length in bytes of the client's challenge to the server to > authenticate itself. Historically, permissible values are between > 16 and 32 bytes inclusive. When using the SSLv2 backward > compatible handshake the client MUST use a 32-byte challenge. > [...] > challenge > Corresponds to ClientHello.random. If the challenge length is > less than 32, the TLS server will pad the data with leading > (note: not trailing) zero bytes to make it 32 bytes long. > > Which is not exactly consistent: if the challenge length MUST be 32 > bytes, it can't be less than 32 bytes. > > It was also noted that for historical and/or compatibility reasons, > many existing browsers (e.g. Opera, IE6, FireFox 1.5) use 16-byte > challenges: > > http://www1.ietf.org/mail-archive/web/tls/current/msg00985.html > > My proposal (in the mail linked above) was to to change this to "The > length of the challenge field in bytes; MUST be between 16 and 32 > (inclusive)." > > Comments? (At the very least, the text needs to be internally > consistent. Preferably it should also promote real-world > interoperability and reflect what implementations are expected to do.) So, here's what I was trying to say: 1. As a TLS 1.2 impl yuou MUST use a 32-byte challenge. 2. Downrev impls may use a 16-32 byte challenge at which point you would pad with zeros but in < 1.2 mode. That may not be the right thing to say. :) -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 10:48: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 1HObtB-0001WH-48; Tue, 06 Mar 2007 10:47:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HObt9-0001W6-Nc for tls@ietf.org; Tue, 06 Mar 2007 10:47:43 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HObt8-0008FI-DE for tls@ietf.org; Tue, 06 Mar 2007 10:47:43 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l26FlZhc003983 for ; Tue, 6 Mar 2007 10:47:35 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l26FlSA2027237 for ; Tue, 6 Mar 2007 10:47:29 -0500 Received: from [127.0.0.1] (vpn-51-29.sfbay.redhat.com [10.14.51.29] (may be forged)) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l26FlOxn016920 for ; Tue, 6 Mar 2007 10:47:26 -0500 Message-ID: <45ED8D09.2060600@redhat.com> Date: Tue, 06 Mar 2007 07:47:21 -0800 From: Wan-Teh Chang User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Re: TLS 1.2 draft References: <20070305054158.3A09C1CC24@delta.rtfm.com> <87zm6qydae.fsf@latte.josefsson.org> In-Reply-To: <87zm6qydae.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Simon Josefsson wrote: > EKR writes: > >> - Replaced the PKCS#1 text with references to PKCS#1 v2. This also >> includes DigestInfo encoding [issues 1 and 22] > > The new text is: > > In RSA signing, the opaque vector contains the signature generated > using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1B]. As > discussed in [PKCS1B], the DigestInfo MUST be DER encoded and for > digest algorithms without parameters (which include SHA-1) the > DigestInfo.AlgorithmIdentifier.parameters field SHOULD be omitted but > implementations MUST accept both without parameters and with NULL > parameters. Note that earlier versions of TLS used a different RSA > signature scheme which did not include a DigestInfo encoding. > > The PKCS#1 v2.1 with erratas, RFC 3447 and IEEE 1363a-2004 includes > hash identifier for SHA-1 that corresponds to a present NULL > parameter: > > SHA-1: (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H. > > Right now, GnuTLS generates NULL and only accepts NULL values. Mike's > server generate NULL, and if I remember correctly, it was based on > OpenSSL. I am not aware of any other TLS 1.2 servers or clients that > are available for testing. NSS hasn't implemented TLS 1.2 yet, but supports the RSASSA-PKCS1-v1_5 signature scheme. NSS generates NULL parameters but accepts both without parameters and with NULL parameters. I was surprised to learn about this change when I read your message. So I did some research. Here is what I found. Appendix H of RFC 3447 explains the change to recommend omitting the parameters for the SHA-x hash algorithms defined by NIST: The following corrections were made in converting the PKCS #1 v2.1 document to this RFC: * The requirement that the parameters in an AlgorithmIdentifier value for id-sha1, id-sha256, id-sha384, and id-sha512 be NULL was changed to a recommendation that the parameters be omitted (while still allowing the parameters to be NULL). This is to align with the definitions originally promulgated by NIST. Implementations MUST accept AlgorithmIdentifier values both without parameters and with NULL parameters. [...] These corrections will be reflected in future editions of PKCS #1 v2.1. This change has been made to PKCS #1 v2.1 in the errata. (ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt) As you pointed out, the authors of RFC 3447 forgot to update the DER encoding of the DigestInfo values for SHA-1, SHA-256, SHA-384, and SHA-512. The DER encoding still contains the NULL parameters (the 05 00 octet sequence near the end). Wan-Teh _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 12:13: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 1HOdD5-00087o-Ei; Tue, 06 Mar 2007 12:12:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOdD4-00087e-94 for tls@ietf.org; Tue, 06 Mar 2007 12:12:22 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOdD1-0005rb-Oe for tls@ietf.org; Tue, 06 Mar 2007 12:12:22 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id SAA25242; Tue, 6 Mar 2007 18:12:12 +0100 (MEZ) From: Martin Rex Message-Id: <200703061712.SAA29545@uw1048.wdf.sap.corp> Subject: Re: [TLS] TLS 1.2 draft To: ekr@networkresonance.com (EKR) Date: Tue, 6 Mar 2007 18:12:12 +0100 (MET) In-Reply-To: <20070305054158.3A09C1CC24@delta.rtfm.com> from "EKR" at Mar 4, 7 09:41: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-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 EKR wrote: > > - Remove ephemeral RSA [issue 3] This makes me sad. I would have SIGNIFICANTLY preferred if temporary/ephemeral RSA had been retained and the restriction to the RSA_EXPORT ciphersuites had been removed instead. As I had previously explained, the use of temporary/ephemeral RSA with same-strength keys as the server's certificate would make key-stealing of the servers' key much less useful for passive attacks. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 12:24:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOdNj-0004vo-G6; Tue, 06 Mar 2007 12:23:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOdNi-0004vi-Ax for tls@ietf.org; Tue, 06 Mar 2007 12:23:22 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOdNh-0007xv-3C for tls@ietf.org; Tue, 06 Mar 2007 12:23:22 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id D91061CC79; Tue, 6 Mar 2007 09:22:29 -0800 (PST) To: martin.rex@sap.com Subject: Re: [TLS] TLS 1.2 draft References: <200703061712.SAA29545@uw1048.wdf.sap.corp> From: EKR Date: Tue, 06 Mar 2007 09:22:29 -0800 In-Reply-To: <200703061712.SAA29545@uw1048.wdf.sap.corp> (Martin Rex's message of "Tue, 6 Mar 2007 18:12:12 +0100 (MET)") Message-ID: <86abyq2soa.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: > EKR wrote: >> >> - Remove ephemeral RSA [issue 3] > > This makes me sad. > > I would have SIGNIFICANTLY preferred if temporary/ephemeral RSA > had been retained and the restriction to the RSA_EXPORT ciphersuites > had been removed instead. > > As I had previously explained, the use of temporary/ephemeral RSA > with same-strength keys as the server's certificate would make > key-stealing of the servers' key much less useful for passive > attacks. The recommendation is to use RSA/DHE for these applications. Can you explain why you think ephemeral RSA is superior? Thanks, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 12:42: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 1HOdfX-0001Vs-Bn; Tue, 06 Mar 2007 12:41:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOdfW-0001Vm-D5 for tls@ietf.org; Tue, 06 Mar 2007 12:41:46 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOdfU-0002e6-0w for tls@ietf.org; Tue, 06 Mar 2007 12:41:46 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id SAA23872; Tue, 6 Mar 2007 18:41:36 +0100 (MEZ) From: Martin Rex Message-Id: <200703061740.SAA00305@uw1048.wdf.sap.corp> Subject: Re: [TLS] TLS 1.2 draft To: ekr@networkresonance.com Date: Tue, 6 Mar 2007 18:40:46 +0100 (MET) In-Reply-To: <86abyq2soa.fsf@delta.rtfm.com> from "EKR" at Mar 6, 7 09:22:29 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: 52e1467c2184c31006318542db5614d5 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 EKR wrote: > > Martin Rex writes: > > > EKR wrote: > >> > >> - Remove ephemeral RSA [issue 3] > > > > This makes me sad. > > > > I would have SIGNIFICANTLY preferred if temporary/ephemeral RSA > > had been retained and the restriction to the RSA_EXPORT ciphersuites > > had been removed instead. > > > > As I had previously explained, the use of temporary/ephemeral RSA > > with same-strength keys as the server's certificate would make > > key-stealing of the servers' key much less useful for passive > > attacks. > > The recommendation is to use RSA/DHE for these applications. Can > you explain why you think ephemeral RSA is superior? The Server's RSA key is typically used for at least one year (or longer if renewal just extends the cert lifetime and keeps the key/keypair). If an attacker gets hold of the Servers private RSA key, he can passively monitor (decrypt) all sessions using a RSA-based ciphersuite. When a temporary/ephemeral keypair is used for key exchange, then possession of the private RSA key will not be sufficient to passively monitor (decrypt) SSL sessions with the server using an RSA ciphersuite with a temporary/ephemeral keypair. It will require an active (MITM) attack. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 12:47: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 1HOdk4-00078B-BV; Tue, 06 Mar 2007 12:46:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOdk2-000754-VC for tls@ietf.org; Tue, 06 Mar 2007 12:46:26 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOdk1-0003Qk-Kn for tls@ietf.org; Tue, 06 Mar 2007 12:46:26 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id D11BB1E8E42; Tue, 6 Mar 2007 09:46:22 -0800 (PST) To: martin.rex@sap.com Subject: Re: [TLS] TLS 1.2 draft References: <200703061740.SAA00305@uw1048.wdf.sap.corp> From: Eric Rescorla Date: Tue, 06 Mar 2007 09:46:22 -0800 In-Reply-To: <200703061740.SAA00305@uw1048.wdf.sap.corp> (Martin Rex's message of "Tue, 6 Mar 2007 18:40:46 +0100 (MET)") Message-ID: <86irdetgcx.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: > EKR wrote: >> >> Martin Rex writes: >> >> > EKR wrote: >> >> >> >> - Remove ephemeral RSA [issue 3] >> > >> > This makes me sad. >> > >> > I would have SIGNIFICANTLY preferred if temporary/ephemeral RSA >> > had been retained and the restriction to the RSA_EXPORT ciphersuites >> > had been removed instead. >> > >> > As I had previously explained, the use of temporary/ephemeral RSA >> > with same-strength keys as the server's certificate would make >> > key-stealing of the servers' key much less useful for passive >> > attacks. >> >> The recommendation is to use RSA/DHE for these applications. Can >> you explain why you think ephemeral RSA is superior? > > The Server's RSA key is typically used for at least one year > (or longer if renewal just extends the cert lifetime and keeps > the key/keypair). > > If an attacker gets hold of the Servers private RSA key, he can > passively monitor (decrypt) all sessions using a RSA-based ciphersuite. > > When a temporary/ephemeral keypair is used for key exchange, then > possession of the private RSA key will not be sufficient to > passively monitor (decrypt) SSL sessions with the server > using an RSA ciphersuite with a temporary/ephemeral keypair. > It will require an active (MITM) attack. Right. I understand this point. What I'm saying is that the recommendation to prevent his attack is to use an RSA_DHE ciphersuite and use a fresh DH ephemeral with each key exchange. This provides the same security at a substantially superior performance level. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 06 12:59: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 1HOdwO-0001ST-On; Tue, 06 Mar 2007 12:59:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOdwN-0001SH-EF for tls@ietf.org; Tue, 06 Mar 2007 12:59:11 -0500 Received: from anchor-post-35.mail.demon.net ([194.217.242.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOdwJ-0005NQ-5d for tls@ietf.org; Tue, 06 Mar 2007 12:59:11 -0500 Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-35.mail.demon.net with esmtp (Exim 4.42) id 1HOdwG-000NQg-Ho for tls@ietf.org; Tue, 06 Mar 2007 17:59:04 +0000 Message-ID: <45EDAC2E.7020606@drh-consultancy.demon.co.uk> Date: Tue, 06 Mar 2007 18:00:14 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] TLS 1.2 draft References: <200703061740.SAA00305@uw1048.wdf.sap.corp> <86irdetgcx.fsf@raman.networkresonance.com> In-Reply-To: <86irdetgcx.fsf@raman.networkresonance.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: > > What I'm saying is that the recommendation to prevent his attack > is to use an RSA_DHE ciphersuite and use a fresh DH ephemeral > with each key exchange. This provides the same security at > a substantially superior performance level. > On the subject of DHE and performance... should we allow a server to optionally send the subprime ("q") value in ServerKeyExchange? 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 Mar 06 13:02: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 1HOdz0-0002S9-Uf; Tue, 06 Mar 2007 13:01:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOdyz-0002Rw-I3 for tls@ietf.org; Tue, 06 Mar 2007 13:01:53 -0500 Received: from anchor-post-34.mail.demon.net ([194.217.242.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOdyy-00062V-8X for tls@ietf.org; Tue, 06 Mar 2007 13:01:53 -0500 Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-34.mail.demon.net with esmtp (Exim 4.42) id 1HOdyx-0004e0-Eg for tls@ietf.org; Tue, 06 Mar 2007 18:01:51 +0000 Message-ID: <45EDACD6.1020804@drh-consultancy.demon.co.uk> Date: Tue, 06 Mar 2007 18:03:02 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Re: TLS 1.2 draft References: <20070305054158.3A09C1CC24@delta.rtfm.com> <87zm6qydae.fsf@latte.josefsson.org> <45ED8D09.2060600@redhat.com> In-Reply-To: <45ED8D09.2060600@redhat.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Wan-Teh Chang wrote: > > NSS generates NULL parameters > but accepts both without parameters and with NULL parameters. > OpenSSL does this also. 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 Mar 07 04:55: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 1HOspj-0002O7-On; Wed, 07 Mar 2007 04:53:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsph-0002JP-Ui for tls@ietf.org; Wed, 07 Mar 2007 04:53:17 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOspf-0005pj-HE for tls@ietf.org; Wed, 07 Mar 2007 04:53:17 -0500 Received: from extundo.com (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l279r09W028069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 10:53:02 +0100 From: Simon Josefsson To: EKR References: <200703061740.SAA00305@uw1048.wdf.sap.corp> <86irdetgcx.fsf@raman.networkresonance.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070307:martin.rex@sap.com::ybz8f6xUZAhT5Y1x:7G76 X-Hashcash: 1:22:070307:tls@ietf.org::lqaJaj9eFeGLEuma:LG/p X-Hashcash: 1:22:070307:ekr@networkresonance.com::Wt1Y8DSxQWCZEhO3:SgCz Date: Wed, 07 Mar 2007 10:53:00 +0100 In-Reply-To: <86irdetgcx.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Tue\, 06 Mar 2007 09\:46\:22 -0800") Message-ID: <87vehdl6rn.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.8 required=4.0 tests=AWL,BAYES_40 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.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tls@ietf.org Subject: [TLS] Re: TLS 1.2 draft 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 writes: > What I'm saying is that the recommendation to prevent his attack > is to use an RSA_DHE ciphersuite I agree with that. However, if I remember correctly, DHE key exchanges are generally slower than plain RSA key exchanges with temporary keys, although it depends on the DH group size. > and use a fresh DH ephemeral with each key exchange. This provides > the same security at a substantially superior performance level. Generating a fresh DH ephemeral with each key exchange would deplete the entropy in many RNG's. Perhaps we could discuss the frequency that DH ephemeral's should be changed, possibly also in the document. There are tools out there that use a static hard-coded DH ephemeral in the code, and some configurations where the DH ephemeral is stored in a separate file, but never re-freshed anyway. I can't find an appropriate section, but section 8.1.2 seems as good as any, so I suggest adding this to the end of it: When ephemeral DH parameters are needed, they SHOULD be re-freshed with some interval appropriate for the local environment. This MAY be for each new key exchange, but MAY also be each day, week or month. That's quite fuzzy, but I'm not sure there are any good recommendations on this. In GnuTLS, I think we recommend to change the DH ephemeral somewhere around each day or week. The change frequency is related to the size of the DH group, I guess, and it would be interesting to know what sizes others default to? GnuTLS uses 1024 bit DHE parameters by default. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 07 07:09: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 1HOuwb-0006vv-4g; Wed, 07 Mar 2007 07:08:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOuwa-0006vq-Dr for tls@ietf.org; Wed, 07 Mar 2007 07:08:32 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOuwZ-0004hv-1h for tls@ietf.org; Wed, 07 Mar 2007 07:08:32 -0500 Received: by machshav.com (Postfix, from userid 512) id 5FDBEFB2A0; Wed, 7 Mar 2007 12:08:24 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5F1E4FB29D; Wed, 7 Mar 2007 12:08:22 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 2FE5176612D; Wed, 7 Mar 2007 07:08:19 -0500 (EST) Date: Wed, 7 Mar 2007 07:08:19 -0500 From: "Steven M. Bellovin" To: Simon Josefsson Subject: Re: [TLS] Re: TLS 1.2 draft In-Reply-To: <87vehdl6rn.fsf@latte.josefsson.org> References: <200703061740.SAA00305@uw1048.wdf.sap.corp> <86irdetgcx.fsf@raman.networkresonance.com> <87vehdl6rn.fsf@latte.josefsson.org> Organization: Columbia University X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.7; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070307120819.2FE5176612D@berkshire.machshav.com> X-Spam-Score: 0.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 On Wed, 07 Mar 2007 10:53:00 +0100 Simon Josefsson wrote: > Eric Rescorla writes: > > > What I'm saying is that the recommendation to prevent his attack > > is to use an RSA_DHE ciphersuite > > I agree with that. However, if I remember correctly, DHE key > exchanges are generally slower than plain RSA key exchanges with > temporary keys, although it depends on the DH group size. The problem is generating the two large primes for the RSA key pair. > > > and use a fresh DH ephemeral with each key exchange. This provides > > the same security at a substantially superior performance level. > > Generating a fresh DH ephemeral with each key exchange would deplete > the entropy in many RNG's. > > Perhaps we could discuss the frequency that DH ephemeral's should be > changed, possibly also in the document. I think the strategy used in JFK (http://www.cs.columbia.edu/~smb/papers/jfk-ccs.pdf) would help. > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 07 09:00: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 1HOwg3-0002jr-RA; Wed, 07 Mar 2007 08:59:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOwg1-0002jm-V2 for tls@ietf.org; Wed, 07 Mar 2007 08:59:33 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOwg0-0001Mr-Ga for tls@ietf.org; Wed, 07 Mar 2007 08:59:33 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l27DxE8R004876; Wed, 7 Mar 2007 15:59:30 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 15:59:27 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 15:59:26 +0200 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] TLS 1.2 draft Date: Wed, 7 Mar 2007 15:59:22 +0200 Message-ID: In-Reply-To: <200703061712.SAA29545@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS 1.2 draft Thread-Index: AcdgEvHs/xJDRVmoQZyuAwv6JJ8AzAArVkpw References: <20070305054158.3A09C1CC24@delta.rtfm.com> from "EKR" at Mar 4, 7 09:41:58 pm <200703061712.SAA29545@uw1048.wdf.sap.corp> From: To: , X-OriginalArrivalTime: 07 Mar 2007 13:59:26.0912 (UTC) FILETIME=[D18E9C00:01C760C0] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070307155930-11D53BB0-0AD06253/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Martin Rex wrote: >=20 > EKR wrote: > >=20 > > - Remove ephemeral RSA [issue 3] >=20 > This makes me sad. One clarification about this: ephemeral RSA was already removed=20 in TLS 1.1 (RFC 4346); issue 3 was an editorial correction to=20 some old text that was still lying around. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 07 09:24: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 1HOx2o-0002XQ-RY; Wed, 07 Mar 2007 09:23:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOx2n-0002WK-5t for tls@ietf.org; Wed, 07 Mar 2007 09:23:05 -0500 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 1HOx2l-0006gd-N3 for tls@ietf.org; Wed, 07 Mar 2007 09:23:05 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l27EMk65021368; Wed, 7 Mar 2007 16:23:01 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 16:23:01 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 16:23:01 +0200 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] Re: TLS 1.2 draft Date: Wed, 7 Mar 2007 16:22:58 +0200 Message-ID: In-Reply-To: <45ED8D09.2060600@redhat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: TLS 1.2 draft Thread-Index: AcdgBvEq28nc0BLpQoGonDwmRMsCkgAue3Gg References: <20070305054158.3A09C1CC24@delta.rtfm.com><87zm6qydae.fsf@latte.josefsson.org> <45ED8D09.2060600@redhat.com> From: To: , X-OriginalArrivalTime: 07 Mar 2007 14:23:01.0501 (UTC) FILETIME=[1CB7C2D0:01C760C4] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070307162301-52051BB0-03797D21/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Wan-Teh Chang wrote: > I was surprised to learn about this change when I read your message. > So I did some research. Here is what I found. >=20 > Appendix H of RFC 3447 explains the change to recommend omitting > the parameters for the SHA-x hash algorithms defined by NIST: >=20 > The following corrections were made in converting the PKCS #1 v2.1 > document to this RFC: >=20 > * The requirement that the parameters in an AlgorithmIdentifier > value for id-sha1, id-sha256, id-sha384, and id-sha512 be > NULL was changed to a recommendation that the parameters be > omitted (while still allowing the parameters to be > NULL). This is to align with the definitions originally > promulgated by NIST. Implementations MUST accept > AlgorithmIdentifier values both without parameters and with > NULL parameters. >=20 > [...] >=20 > These corrections will be reflected in future editions of PKCS #1 > v2.1. >=20 > This change has been made to PKCS #1 v2.1 in the errata. > (ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt) No, this is not exactly what pkcs-1v2-1errata.txt says; there is additional text in the errata: Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5=20 (see 9.2), the parameters field associated with id-sha1, id-sha256,=20 id-sha384 and id-sha512 SHALL have a value of type NULL. This is to=20 maintain compatibility with existing implementations and with the=20 numeric information values already published for EMSA-PKCS1-V1.5=20 which are also reflected in IEEE 1363a-2004[27]. In other words: AlgorithmIdentifier is used in several different places, and the text "MUST accept both, SHOULD omit" applies to=20 all of those *except* one place (EMSA-PKCS1-V1.5). But that place happens to be the one we care about for TLS 1.2 (ServerKeyExchange and CertificateVerify messages)! I think we should follow pkcs-1v2-1errata.txt and IEEE 1363a-2004 (which both agree) here, unless there are compelling arguments against it... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 07 09:27:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOx6P-0004fk-M5; Wed, 07 Mar 2007 09:26:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOx6N-0004eu-Vx for tls@ietf.org; Wed, 07 Mar 2007 09:26:47 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOx6M-0007Vh-KC for tls@ietf.org; Wed, 07 Mar 2007 09:26:47 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id PAA28033; Wed, 7 Mar 2007 15:26:12 +0100 (MEZ) From: Martin Rex Message-Id: <200703071422.PAA28929@uw1048.wdf.sap.corp> Subject: Re: [TLS] Re: TLS 1.2 draft To: smb@cs.columbia.edu (Steven M. Bellovin) Date: Wed, 7 Mar 2007 15:22:04 +0100 (MET) In-Reply-To: <20070307120819.2FE5176612D@berkshire.machshav.com> from "Steven M. Bellovin" at Mar 7, 7 07:08:19 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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: simon@josefsson.org, 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 Steven M. Bellovin wrote: > > On Wed, 07 Mar 2007 10:53:00 +0100 > Simon Josefsson wrote: > > > Eric Rescorla writes: > > > > > What I'm saying is that the recommendation to prevent his attack > > > is to use an RSA_DHE ciphersuite > > > > I agree with that. However, if I remember correctly, DHE key > > exchanges are generally slower than plain RSA key exchanges with > > temporary keys, although it depends on the DH group size. > > The problem is generating the two large primes for the RSA key pair. I agree that a full RSA keygen, in particular for same-size (>=1024 bit) temporary RSA keypairs as the servers certificate is a sure performance-killer. However, the protocol does not preclude the use of an SSL servers temporary keypair for multiple handshakes, say one or a few hours. SSH servers have been doing this for years. I admit to have very little experience with most crypto math and never implemented cryptographic algorithms myself. I do maintenance on code that implements RSA, but I have never looked at code for DH, so I can not really comment on that. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 07 10:27: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 1HOy2F-0001uk-VF; Wed, 07 Mar 2007 10:26:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOy2F-0001tn-3h for tls@ietf.org; Wed, 07 Mar 2007 10:26:35 -0500 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 1HOy2D-0001Ec-J7 for tls@ietf.org; Wed, 07 Mar 2007 10:26:35 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l27FQUlQ007918; Wed, 7 Mar 2007 17:26:31 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 17:26:26 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 17:26:25 +0200 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] Re: TLS 1.2 draft Date: Wed, 7 Mar 2007 17:26:25 +0200 Message-ID: In-Reply-To: <87vehdl6rn.fsf@latte.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: TLS 1.2 draft Thread-Index: AcdgnudGDFrOrLnuQ7m7VZanLCCf4wAJWvzg References: <200703061740.SAA00305@uw1048.wdf.sap.corp><86irdetgcx.fsf@raman.networkresonance.com> <87vehdl6rn.fsf@latte.josefsson.org> From: To: , X-OriginalArrivalTime: 07 Mar 2007 15:26:25.0998 (UTC) FILETIME=[F85FEEE0:01C760CC] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070307172631-19C78BB0-5E97B95E/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 Simon Josefsson wrote: > Generating a fresh DH ephemeral with each key exchange would=20 > deplete the entropy in many RNG's. The normal RSA ciphersuites require far more bytes from PRNG for=20 each key exchange (although only on the client side), and I=20 haven't heard that this would be a significant problem. > I can't find an appropriate section, but section 8.1.2 seems as good > as any, so I suggest adding this to the end of it: >=20 > When ephemeral DH parameters are needed, they SHOULD be > re-freshed with some interval appropriate for the local > environment. This MAY be for each new key exchange, but MAY also > be each day, week or month. >=20 > That's quite fuzzy, but I'm not sure there are any good > recommendations on this. In GnuTLS, I think we recommend to change > the DH ephemeral somewhere around each day or week. Considering that generating fresh DH private value costs about=20 the same as one TLS handshake with DHE, I'd say even a day would be a very large interval. IKEv2 took the view that since this doesn't affect interoperability,=20 there's no need to mandate anything in the spec (RFC 4306, Section 2.12). However, maybe some guidance would be helpful (especially if there really are implementations that store the "ephemeral" DH key in a file!). Earlier, I also suggested that we should recommend *against* generating new DH domain parameters: http://www1.tools.ietf.org/wg/tls/trac/ticket/35 Eric responded that this is not specific to TLS, and could be a=20 separate document. That's of course true, but currently we don't=20 have any normative dependency to documents that explain=20 how to do DH securely. And I do agree with the sentiment expressed=20 in IETF67's SAAG presentation that RFCs should include advice on=20 how to implement them securely (especially for things that people earlier have gotten wrong). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 07 10:31: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 1HOy6b-000600-Mq; Wed, 07 Mar 2007 10:31:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOy6a-0005yS-Nk for tls@ietf.org; Wed, 07 Mar 2007 10:31:04 -0500 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 1HOy6Y-0001lh-Tf for tls@ietf.org; Wed, 07 Mar 2007 10:31:04 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l27FUfO9020070; Wed, 7 Mar 2007 17:31:00 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 17:30:46 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 17:30:45 +0200 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] TLS 1.2 draft (issue #25 about SSLv2 Hello) Date: Wed, 7 Mar 2007 17:30:46 +0200 Message-ID: In-Reply-To: <86mz2q2yc9.fsf@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS 1.2 draft (issue #25 about SSLv2 Hello) Thread-Index: AcdgAxAk68XPiS/PSnCHuQp6o7giEAAyiJpQ References: <20070305054158.3A09C1CC24@delta.rtfm.com> <86mz2q2yc9.fsf@delta.rtfm.com> From: To: X-OriginalArrivalTime: 07 Mar 2007 15:30:46.0090 (UTC) FILETIME=[9366D2A0:01C760CD] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 ekr@networkresonance.com wrote: > So, here's what I was trying to say: >=20 > 1. As a TLS 1.2 impl yuou MUST use a 32-byte challenge. > 2. Downrev impls may use a 16-32 byte challenge at which point > you would pad with zeros but in < 1.2 mode. >=20 > That may not be the right thing to say. :) Ok, now I understood what you meant. But perhaps this spec is=20 not really the right place to say what e.g. TLS 1.0 implementations=20 should do when TLS 1.0 is negotiated :) I'd be OK with Mike's proposal ("length MUST be between 16 and 32 bytes, and add that it SHOULD be 32 bytes"). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 07 10:46: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 1HOyKr-0001LE-J1; Wed, 07 Mar 2007 10:45:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyKq-0001JH-26 for tls@ietf.org; Wed, 07 Mar 2007 10:45:48 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOyKo-0003FU-PR for tls@ietf.org; Wed, 07 Mar 2007 10:45:48 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l27FjNLb018436 for ; Wed, 7 Mar 2007 10:45:44 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l27FWlCA015965 for ; Wed, 7 Mar 2007 10:32:47 -0500 Received: from [127.0.0.1] (vpn-51-44.sfbay.redhat.com [10.14.51.44] (may be forged)) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l27FWd5I029456 for ; Wed, 7 Mar 2007 10:32:46 -0500 Message-ID: <45EEDB21.6030906@redhat.com> Date: Wed, 07 Mar 2007 07:32:49 -0800 From: Wan-Teh Chang User-Agent: Thunderbird 2.0pre (Windows/20070211) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Re: TLS 1.2 draft References: <20070305054158.3A09C1CC24@delta.rtfm.com><87zm6qydae.fsf@latte.josefsson.org> <45ED8D09.2060600@redhat.com> 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: ea4ac80f790299f943f0a53be7e1a21a 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 Pasi.Eronen@nokia.com wrote: > > No, this is not exactly what pkcs-1v2-1errata.txt says; there > is additional text in the errata: > > Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5 > (see 9.2), the parameters field associated with id-sha1, id-sha256, > id-sha384 and id-sha512 SHALL have a value of type NULL. This is to > maintain compatibility with existing implementations and with the > numeric information values already published for EMSA-PKCS1-V1.5 > which are also reflected in IEEE 1363a-2004[27]. > > In other words: AlgorithmIdentifier is used in several different > places, and the text "MUST accept both, SHOULD omit" applies to > all of those *except* one place (EMSA-PKCS1-V1.5). But that place > happens to be the one we care about for TLS 1.2 (ServerKeyExchange > and CertificateVerify messages)! Pasi, you're right. Thank you for correcting me. I didn't see the Exception paragraph. This is complicated. > I think we should follow pkcs-1v2-1errata.txt and IEEE 1363a-2004 > (which both agree) here, unless there are compelling arguments > against it... Since pkcs-1v2-1errata.txt (Dec. 2005) is newer in RFC 3447 (Feb. 2003), I agree with your recommendation. Wan-Teh _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 07 11:12: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 1HOyjh-0000d7-1D; Wed, 07 Mar 2007 11:11:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyjc-0000al-0J; Wed, 07 Mar 2007 11:11:24 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOyjb-0006Gr-Ln; Wed, 07 Mar 2007 11:11:23 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2E13F17744; Wed, 7 Mar 2007 15:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOyOw-0006Ts-FN; Wed, 07 Mar 2007 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 10:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc4346-bis-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 --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-03.txt Pages : 96 Date : 2007-3-7 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-03.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-03.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-03.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-3-7091803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc4346-bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc4346-bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7091803.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 Wed Mar 07 11:12:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyk0-00019g-JT; Wed, 07 Mar 2007 11:11:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyjh-0000dD-57 for tls@ietf.org; Wed, 07 Mar 2007 11:11:29 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOyjT-0000K7-HQ for tls@ietf.org; Wed, 07 Mar 2007 11:11:29 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 1C7E31CC78; Wed, 7 Mar 2007 08:10:16 -0800 (PST) To: Simon Josefsson In-reply-to: Your message of "Wed, 07 Mar 2007 10:53:00 +0100." <87vehdl6rn.fsf@latte.josefsson.org> X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Wed, 07 Mar 2007 08:10:16 -0800 From: EKR Message-Id: <20070307161016.1C7E31CC78@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: tls@ietf.org Subject: [TLS] Re: TLS 1.2 draft 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: > Eric Rescorla writes: > > > What I'm saying is that the recommendation to prevent his attack > > is to use an RSA_DHE ciphersuite > > I agree with that. However, if I remember correctly, DHE key > exchanges are generally slower than plain RSA key exchanges with > temporary keys, although it depends on the DH group size. This is discussed pretty extensively in "SSL and TLS". From memory, on the server side there are three time consuming steps in the ephemeral RSA computation: 1. Generating the ephemeral RSA key 2. Signing the ephemeral RSA key with the static RSA key. 3. Decrypting the PMS encrypted under the ephemeral RSA key. The first can be amortized over a large number of transactions, so really we're talking about (2) and (3). In RSA-DHE, there are three costs as well: 1. Generating the DH ephemeral. 2. Signing the ephemeral DH key with the static RSA key. 3. Computing the DH ZZ. However step 1 can actually be made quite fast by using a short DH exponent and/or using a squaring table, so the dominant costs are (2) and (3). (2) is obviously the same, which leaves us with (3), which is comparable in both cases. So, on the server side, the costs are fairly comparable. On the client side, DHE is much more expensive since you need to do (1) and (2). But the cost of one computation is typically relatively small compared to people's perceptual times (order 50 ms) and clients tend to be low volume, so it's not an issue except for very slow machines. > > and use a fresh DH ephemeral with each key exchange. This provides > > the same security at a substantially superior performance level. > > Generating a fresh DH ephemeral with each key exchange would deplete > the entropy in many RNG's. I don't understand this point. Most TLS implementations use the PRNG to generate the random values as well as the session IDs. You quickly get to the point where you've exposed vastly more bits of entropy than your underlying PRNG state. If your PRNG can't handle this, you need a new PRNG. > Perhaps we could discuss the frequency that DH ephemeral's should be > changed, possibly also in the document. > > There are tools out there that use a static hard-coded DH ephemeral in > the code, and some configurations where the DH ephemeral is stored in > a separate file, but never re-freshed anyway. DH has two parts: 1. The group parameters. 2. The ephemeral share (g^x mod p). The group parameters never need refreshing. The ephemeral share needs to be secret so hardcoding it sees like a pretty bad idea. Standard practice is to generate a fresh ephemeral for every connection but you can amortize if you're careful. In particular, you have to worry about small subgroup issues so it starts to get a lot more important to use S-G primes. I can try to draft up some guidance here based on Zuccheratto's S/MIME draft, but if someone (Bodo?) wanted to contribute some text, I wouldn'tcomplain :) -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Mar 08 11:32: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 1HPLVb-0005EN-Ma; Thu, 08 Mar 2007 11:30:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPLVa-0005EI-I0 for tls@ietf.org; Thu, 08 Mar 2007 11:30:26 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPLVZ-0007xH-0S for tls@ietf.org; Thu, 08 Mar 2007 11:30:26 -0500 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 8 Mar 2007 16:30:24 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Thu, 8 Mar 2007 16:30:24 +0000 From: Stefan Santesson To: Eric Rescorla , "tls@ietf.org" Date: Thu, 8 Mar 2007 16:30:23 +0000 Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: Acc+YydFJXSvnnDOR+i2EMwn5y51OAHwpByABt42Z5A= Message-ID: References: <20070122202751.CCBC45C01E@laser.networkresonance.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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, I never got any response on this posting to the list. I have sent a request to put this on the agenda for Prague. It would be great if we could continue the discussion so we could get to an= agreement on the future of this draft in Prague, or shortly thereafter. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Stefan Santesson > Sent: den 1 februari 2007 19:09 > To: 'Eric Rescorla'; tls@ietf.org > Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00 > > Eric, > > Thank you for the review and the initiative to get a discussion going > on this draft. > > All of your comments are valid and lines up with what I thought would > be the critical issues to discuss. In the end it's a question of > whether these changes to TLS are defendable in relation to the benefit > to the industry and the usability of the protocol. > > Response to your comments 1-3. > > 1) TLS gets no guarantee of the quality of parameters given by GSS-API. > But TLS is no entity so in a way that is the wrong question. The > implementers of this protocol choose to trust the properties of their > GSS-API based technology. The solution of this draft enables them to > extend the trusted authentication methods for TLS sessions to the GSS- > API methods they already use and trust. This can't accidently degrade > the security for regular TLS users. But this is nothing new. This line > was already crossed by RFC 2712. > > 2) The extended roundtrips is an un-escapable consequence. If necessary > I believe we can define an upper boundary of the number of roundtrips. > You are right that the TLS state machine must rely on GSS-API for > validating and concluding the GSS-API exchange. Without being handed > the resulting key material from the GSS-API layer, the TLS state > machine must fail. I feel convinced that it is possible to define the > appropriate set of rules for the TLS state machine on when to close the > connection and fail graciously. > > 3) I believe the precedent was set by RFC 2712. Security wise we do > nothing worse than RFC 2712 already do. This draft do however solve a > number of problems with RFC 2712. I do not agree that this makes a hole > in TLS. This feature will not be enabled unless its specifically agreed > between the parties who thereby make the decision to trust GSS-API to > provide authentication and keying material. > > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > Sent: den 22 januari 2007 21:20 > > To: tls@ietf.org > > Subject: [TLS] Review of draft-santesson-tls-gssapi-00 > > > > $Id: draft-santesson-tls-gssapi-00-rev.txt,v 1.3 2007/01/22 20:27:34 > > ekr Exp $ > > > > I have reviewed this document and as I indicated in San Diego, I have > > serious architectural concerns about the way that it interconnects > TLS > > and GSS-API. > > > > 1. It's totally unclear what security guarantees TLS is supposed > > to be getting from GSS. In fact, it's not possible to be clear > > because there is just some set of mechanism IDs. That may be > > fine in limited environments but it's not fine in the general case > > where other extensions might be used with TLS. > > > > 2. TLS assumes a fixed number of round trips which is determinable > > from the resumption state. By contrast, once this draft establishes > > that GSS is to be used, an arbitrary number of round trips may occur > > in some way that is invisible to TLS. First, that's a big change to > > the state machine and second it's architecturally problematic. It's > > true that there's an indicator in the message for whether it's the > > last payload or not, but there's no way for the TLS state machine to > > independently determine whether that has been tampered with. It needs > > to rely on the GSS state machine. That's problematic both from an > > engineering and security standpoint. > > > > 3. It sets a precedent that the way to interconnect TLS to external > > security mechanisms is via creating a hole in TLS to carry their > > mechanisms. This makes TLS more complicated, which is of course > > the enemy of security protocols. > > > > > > TLS provides a generic mechanism for linking up to externally > exchanged > > keys, courtesy of RFC 4279. All you need to do is arrange for your > > mechanism to create a PSK-Identity binding on both sides and then > > you can do an ordinary TLS exchange using TLS PSK. > > > > In the WG meeting, I heard concerns from the proponents of this draft > > that they then needed to arrange a way to carry the GSS handshake and > > that since their application protocols already had a cutout for TLS > > they wanted to exploit that cutout. I'm not insensitive to this > point, > > but that doesn't make it architecturally sound. > > > > > > -Ekr > > > > _______________________________________________ > > 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 Mar 08 12: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 1HPMVN-0005lK-BE; Thu, 08 Mar 2007 12:34:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPMVL-0005l5-PD for tls@ietf.org; Thu, 08 Mar 2007 12:34:15 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPMVK-0002y6-Bu for tls@ietf.org; Thu, 08 Mar 2007 12:34:15 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 84A6B1E8C5D; Thu, 8 Mar 2007 09:34:13 -0800 (PST) To: Stefan Santesson Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 References: <20070122202751.CCBC45C01E@laser.networkresonance.com> From: Eric Rescorla Date: Thu, 08 Mar 2007 09:34:13 -0800 In-Reply-To: (Stefan Santesson's message of "Thu, 8 Mar 2007 16:30:23 +0000") Message-ID: <86mz2nr65m.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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 Stefan Santesson writes: >> Thank you for the review and the initiative to get a discussion going >> on this draft. >> >> All of your comments are valid and lines up with what I thought would >> be the critical issues to discuss. In the end it's a question of >> whether these changes to TLS are defendable in relation to the benefit >> to the industry and the usability of the protocol. >> >> Response to your comments 1-3. >> >> 1) TLS gets no guarantee of the quality of parameters given by GSS-API. >> But TLS is no entity so in a way that is the wrong question. The >> implementers of this protocol choose to trust the properties of their >> GSS-API based technology. The solution of this draft enables them to >> extend the trusted authentication methods for TLS sessions to the GSS- >> API methods they already use and trust. This can't accidently degrade >> the security for regular TLS users. But this is nothing new. This line >> was already crossed by RFC 2712. I don't agree. RFC 2712 had a clear interface to Kerberos, namely a ticket was in the ClientKeyExchange. I'm not saying that worked, but it was clear. By contrast this draft just creates a hole where you can shove arbitrary GSS messages, as evidenced by the fact that you have to extend the state machine to allow an arbitrary number of roundtrips. >> 2) The extended roundtrips is an un-escapable consequence. If necessary >> I believe we can define an upper boundary of the number of roundtrips. Well, any number >2 is a radical change in the TLS state machine. >> 3) I believe the precedent was set by RFC 2712. Security wise we do >> nothing worse than RFC 2712 already do. This draft do however solve a >> number of problems with RFC 2712. I do not agree that this makes a hole >> in TLS. Obviously, we disagree on this point. >> This feature will not be enabled unless its specifically agreed >> between the parties who thereby make the decision to trust GSS-API to >> provide authentication and keying material. It seems to me that this argument could be used to justify any new cipher suite, no matter how broken. The purpose of having a TLS WG is to decide whether new extensions are worth doing, not to punt the decision to users. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Mar 08 12:53: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 1HPMmu-0008S8-BP; Thu, 08 Mar 2007 12:52:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPMmt-0008Rw-0n for tls@ietf.org; Thu, 08 Mar 2007 12:52:23 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPMmk-0006ta-3u for tls@ietf.org; Thu, 08 Mar 2007 12:52:23 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id SAA07050; Thu, 8 Mar 2007 18:52:02 +0100 (MEZ) From: Martin Rex Message-Id: <200703081752.SAA13445@uw1048.wdf.sap.corp> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 To: stefans@microsoft.com (Stefan Santesson) Date: Thu, 8 Mar 2007 18:52:02 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Mar 8, 7 04:30:23 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: 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 Stefan Santesson wrote: > > I never got any response on this posting to the list. > I have sent a request to put this on the agenda for Prague. > > It would be great if we could continue the discussion so we could get > to an agreement on the future of this draft in Prague, or shortly thereafter. I do not like the key-exchange in draft-santesson-tls-gssapi-00.txt. Since the architecture leaves the message protection completely up to the TLS layer, it should also do this with the key exchange and _limit_ the GSS-API involvement to (a) authentication and (b) mixing gss-api provided entropy (if available) with traditional TLS-provided entropy for the pre-master secret. IMHO, the key exchange should be either DHE or RSA-encryption, where the latter will require an RSA-based server certificate, even if self-signed. The current proposal comes with too many ifs/restrictions for my taste. GSS-API does allow authentication-only and no-encryption gssapi mechanisms and the current proposal precludes their use, and I also don't think that we should mandate the availability of gss_prf functionality even for those mechanisms where this optional feature has recently be specified. Authentication-only gssapi mechanisms as well as integrity-only gssapi mechanisms will be unable to provide protection for the key exchange, which is why I think we should stick completely to the original SSL/TLS key exchange algorithms. One idea to mix the gssapi authentication into the key exchange would be to exchange a strong random string of the same length as the pre-master secret protected with the gssapi message protection gss_wrap(conf=true) and XOR it with the pre-master secret that is protected with the traditional TLS key exchange algorithm before use. This extra random protected by gss_wrap(conf=true) should probably be generated by the server right after successful context establishment and sent to the client and should be applied (XOR'ed) by the client _after_ sending the ClientKeyExchange message and applied by the server after receiving the ClientKeyExchange message. The strength of the binding between the GSS-API authentication and the TLS communication channel will only be as strong as the gss_api message protection itself (i.e. no binding for authentication- and integrity-only gss-api mechanisms), but that is probably as good as it can get. Limiting the strength of the key exchange of a cipher suite like TLS_GSS_API_WITH_AES_256_CBC_SHA to a single-DES-based gssapi authentication seems to be a bad idea. In contast to that, securely mixing in additional entropy from gssapi authentication into a regular TLS key exchange shouldn't hurt. SSL/TLS (in contrast to GSS-API) was invented to provide a broad level of interoperability _on_the_wire_, while GSS-API was invented to provide interoperability NOT _on_the_wire_ but at the API level (as an extreme plug'n'play) between applications and GSS-API mechanisms, and at the same time being strictly limited to a particular gss-api mechanism and a single user-management/namespace. Setting up and using clients and servers with a future TLS-stack that allows for gss-api based authentication but rejects all cipher-suites without gss-api authentication (or makes it quite difficult for the users/admins to enable&configure non-gssapi ciphersuites), is IMHO heading in the wrong direction. Initial specs had a strong focus on interoperability (in order to establish a protected communication channel), ultimately leaving it up to the application to figure out ways to secure the authentication process (server-side uses the well-known endpoint identification, client-side SSL certs are still rare, and obvious design flaws in installed base (WinHTTP) make it difficult to migrate to SSL client certs today. So in the tradition of interoperability, I'd really like to see a requirement for future TLS implementations with support for gssapi-based authentication that they must offer alternative ciphersuites (ciphersuites with traditional server-authentication based on a Server certificate), and that these must be enabled by default (and only be disabled if the admin explicitly configures it that way). We will have to wiggle out the details. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 05:51:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcfN-0001mB-3I; Fri, 09 Mar 2007 05:49:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcfL-0001ky-1L for tls@ietf.org; Fri, 09 Mar 2007 05:49:39 -0500 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 1HPcfJ-0002jE-JH for tls@ietf.org; Fri, 09 Mar 2007 05:49:39 -0500 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 l29AnOrZ000886 for ; Fri, 9 Mar 2007 12:49:35 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 12:49:08 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 12:49:08 +0200 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] Review of draft-santesson-tls-gssapi-00 Date: Fri, 9 Mar 2007 12:49:11 +0200 Message-ID: In-Reply-To: <86mz2nr65m.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdhqFCB2U/5EcZdTnq3MGCYPQF54wAjJcmg References: <20070122202751.CCBC45C01E@laser.networkresonance.com> <86mz2nr65m.fsf@raman.networkresonance.com> From: To: X-OriginalArrivalTime: 09 Mar 2007 10:49:08.0332 (UTC) FILETIME=[906112C0:01C76238] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 Eric Rescorla wrote: > >> 2) The extended roundtrips is an un-escapable consequence. If > >> necessary I believe we can define an upper boundary of the number > >> of roundtrips. >=20 > Well, any number >2 is a radical change in the TLS state machine. I agree; however, there are several ways to do the roundtrips, and some of them might be slightly less radical than the one current proposed in draft-santesson-tls-gssapi-01. Here's one sketch of how this could work: ClientHello (ciphersuite TLS_RSA_GSSAPI_WITH_AES128_CBC_SHA,=20 gss_api extension with OID list) --------> ServerHello (gss_api extension with OID list) Certificate <-------- ServerHelloDone ClientKeyExchange=20 (just like in normal RSA ciphersuites) ChangeCipherSpec Finished --------> ChangeCipherSpec <-------- Finished Then we'd have the GSSAPI exchange: ContentType=3DGSSAPI=20 ("token", gss token data) --------> =20 ContentType=3DGSSAPI <--- ("token", gss token data) =20 (........ repeat 0..N times ..........) ContentType=3DGSSAPI ("complete",=20 gss_wrap(channel binding info)) -----> ContentType=3DGSSAPI ("complete",=20 gss_wrap(channel binding info)) Application Data <-------> Application Data Here "channel binding info" would be something similar as in draft-williams-on-channel-binding-01. Using a different content type and channel binding would avoid the need to feed stuff from GSS-API=20 to TLS record layer/handshake layer/key calculations (which AFAIK=20 was one thing Eric objected to in IETF67). (In addition to TLS_RSA_GSSAPI_WITH_*, we could also have TLS_DHE_GSSAPI_WITH_* ciphersuites, if we need to support servers without a certificate.) Comments?=20 Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 08:27: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 1HPf6j-0004Gm-8b; Fri, 09 Mar 2007 08:26:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPf6i-0004ES-Lw for tls@ietf.org; Fri, 09 Mar 2007 08:26:04 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPf6h-0002ah-5x for tls@ietf.org; Fri, 09 Mar 2007 08:26:04 -0500 Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l29DPL5X006544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2007 14:25:21 +0100 From: Simon Josefsson To: References: <20070122202751.CCBC45C01E@laser.networkresonance.com> <86mz2nr65m.fsf@raman.networkresonance.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070309:tls@ietf.org::mbzRlJwgagSNjotA:GD5t X-Hashcash: 1:22:070309:pasi.eronen@nokia.com::RX8Q/I1DwNC0P1Cr:CP6a Date: Fri, 09 Mar 2007 14:25:21 +0100 In-Reply-To: (Pasi Eronen's message of "Fri\, 9 Mar 2007 12\:49\:11 +0200") Message-ID: <87hcsulfb2.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.0 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.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tls@ietf.org Subject: [TLS] Re: Review of draft-santesson-tls-gssapi-00 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 writes: > Eric Rescorla wrote: > >> >> 2) The extended roundtrips is an un-escapable consequence. If >> >> necessary I believe we can define an upper boundary of the number >> >> of roundtrips. >> >> Well, any number >2 is a radical change in the TLS state machine. > > I agree; however, there are several ways to do the roundtrips, > and some of them might be slightly less radical than the one > current proposed in draft-santesson-tls-gssapi-01. > > Here's one sketch of how this could work: > > ClientHello > (ciphersuite TLS_RSA_GSSAPI_WITH_AES128_CBC_SHA, > gss_api extension with OID list) I like this approach better, although I don't understand why you need special GSSAPI ciphersuites, could you explain? Wouldn't it be possible to do this with an extension, to enable the extra roundtrips, without touching the ciphersuites? > gss_wrap(channel binding info)) -----> Using gss_wrap to wrap additional information, such as channel bindings, has some similarities with the SASL GS2 mechanism. Note that it doesn't seem to work with authentication-only GSS-API mechanisms that doesn't support GSS_Wrap. In general, I'm in favor of any protocol that permits GSS-API negotiation inside TLS but outside of the application data exchange. The details are less important to me, and I think it should be possible to come up with a good compromise here. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 09:04: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 1HPfhP-0005KK-17; Fri, 09 Mar 2007 09:03:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPfhM-0005Jv-TD for tls@ietf.org; Fri, 09 Mar 2007 09:03:56 -0500 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 1HPfhJ-0007Os-0e for tls@ietf.org; Fri, 09 Mar 2007 09:03:56 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l29E3efM028939 for ; Fri, 9 Mar 2007 16:03:51 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 16:03:35 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 16:03:35 +0200 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, 9 Mar 2007 16:03:18 +0200 Message-ID: In-Reply-To: <87hcsulfb2.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdiToQt3LbZlHE+R/yN4LA37DTN8gABHu3Q References: <20070122202751.CCBC45C01E@laser.networkresonance.com><86mz2nr65m.fsf@raman.networkresonance.com> <87hcsulfb2.fsf@mocca.josefsson.org> From: To: X-OriginalArrivalTime: 09 Mar 2007 14:03:35.0033 (UTC) FILETIME=[BA465E90:01C76253] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070309160351-6F1DDBB0-161751C3/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [TLS] RE: Review of draft-santesson-tls-gssapi-00 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: > > Here's one sketch of how this could work: > > > > ClientHello > > (ciphersuite TLS_RSA_GSSAPI_WITH_AES128_CBC_SHA,=20 > > gss_api extension with OID list) >=20 > I like this approach better, although I don't understand why you need > special GSSAPI ciphersuites, could you explain? Wouldn't it be > possible to do this with an extension, to enable the extra roundtrips, > without touching the ciphersuites? I'm not sure if we really need special GSSAPI ciphersuites either... But at least it would allow the client to say "I want to do RSA+GSS-API, not plain RSA" in a way that would be correctly understood by existing servers (that don't do GSS-API). > Using gss_wrap to wrap additional information, such as channel > bindings, has some similarities with the SASL GS2 mechanism. Note > that it doesn't seem to work with authentication-only GSS-API > mechanisms that doesn't support GSS_Wrap. Hmm... possibly it should be GSS_GetMIC instead of GSS_Wrap? Are there any important GSS-API mechanisms that support neither? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 09:32: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 1HPg7j-0002Hq-6X; Fri, 09 Mar 2007 09:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPg7h-0002CL-N8 for tls@ietf.org; Fri, 09 Mar 2007 09:31:09 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPg7g-0003VA-6R for tls@ietf.org; Fri, 09 Mar 2007 09:31:09 -0500 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 9 Mar 2007 14:30:53 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 9 Mar 2007 14:30:53 +0000 From: Stefan Santesson To: "martin.rex@sap.com" Date: Fri, 9 Mar 2007 14:30:51 +0000 Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: Acdhqo61pdqygbq4QHGTxTAqzHWTpQAq3q5A Message-ID: References: from "Stefan Santesson" at Mar 8, 7 04:30:23 pm <200703081752.SAA13445@uw1048.wdf.sap.corp> In-Reply-To: <200703081752.SAA13445@uw1048.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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 and Martin, Thank you for elaborate comments on your positions. Before getting into detailed discussions on your comments, I would like to = figure out the principles of concerns and figure out if there is any common= ground we could build this on. As I understand you have 2 major concerns: 1) That the TLS state Machine has not control over the resulting security o= f TLS. I.e. if a bad GSS-API mechanism is deployed, it would degrade the se= curity of TLS. 2) That the GSS-API exchange requires more than 1 roundtrip of messages to = be completed. Martin suggested a method for ensuring at least TLS level security. This ha= s also crossed my mind but we decided not to go there initially. But how mu= ch concern would go away if we did this in a way where at least TLS securit= y level is achieved? If the TLS state machine still have control over the security level of the = encryption key, would it still be a problem that several roundtrips is requ= ired for the GSS exchange? If so, why is this a problem, except from an emotional purity perspective. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com] > Sent: den 8 mars 2007 18:52 > To: Stefan Santesson > Cc: ekr@networkresonance.com; tls@ietf.org > Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 > > > Stefan Santesson wrote: > > > > I never got any response on this posting to the list. > > I have sent a request to put this on the agenda for Prague. > > > > It would be great if we could continue the discussion so we could get > > to an agreement on the future of this draft in Prague, or shortly > thereafter. > > I do not like the key-exchange in draft-santesson-tls-gssapi-00.txt. > > Since the architecture leaves the message protection completely up > to the TLS layer, it should also do this with the key exchange > and _limit_ the GSS-API involvement to (a) authentication and > (b) mixing gss-api provided entropy (if available) with > traditional TLS-provided entropy for the pre-master secret. > > IMHO, the key exchange should be either DHE or RSA-encryption, > where the latter will require an RSA-based server certificate, > even if self-signed. > > The current proposal comes with too many ifs/restrictions for my taste. > > GSS-API does allow authentication-only and no-encryption gssapi > mechanisms and the current proposal precludes their use, and I also > don't think that we should mandate the availability of gss_prf > functionality even for those mechanisms where this optional feature > has recently be specified. > > Authentication-only gssapi mechanisms as well as integrity-only > gssapi mechanisms will be unable to provide protection for the > key exchange, which is why I think we should stick completely > to the original SSL/TLS key exchange algorithms. > > One idea to mix the gssapi authentication into the key exchange > would be to exchange a strong random string of the same length > as the pre-master secret protected with the gssapi message > protection gss_wrap(conf=3Dtrue) and XOR it with the > pre-master secret that is protected with the traditional TLS > key exchange algorithm before use. This extra random protected > by gss_wrap(conf=3Dtrue) should probably be generated by the server > right after successful context establishment and sent to the client > and should be applied (XOR'ed) by the client _after_ sending the > ClientKeyExchange message and applied by the server after receiving > the ClientKeyExchange message. > > The strength of the binding between the GSS-API authentication > and the TLS communication channel will only be as strong as the > gss_api message protection itself (i.e. no binding for authentication- > and integrity-only gss-api mechanisms), but that is probably as good > as it can get. > > Limiting the strength of the key exchange of a cipher suite like > TLS_GSS_API_WITH_AES_256_CBC_SHA to a single-DES-based gssapi > authentication seems to be a bad idea. > In contast to that, securely mixing in additional entropy from gssapi > authentication into a regular TLS key exchange shouldn't hurt. > > > SSL/TLS (in contrast to GSS-API) was invented to provide a broad > level of interoperability _on_the_wire_, while GSS-API was invented > to provide interoperability NOT _on_the_wire_ but at the API level > (as an extreme plug'n'play) between applications and GSS-API > mechanisms, > and at the same time being strictly limited to a particular gss-api > mechanism and a single user-management/namespace. > > > Setting up and using clients and servers with a future TLS-stack > that allows for gss-api based authentication but rejects all > cipher-suites without gss-api authentication (or makes it quite > difficult for the users/admins to enable&configure non-gssapi > ciphersuites), is IMHO heading in the wrong direction. > > > Initial specs had a strong focus on interoperability (in order to > establish a protected communication channel), ultimately leaving > it up to the application to figure out ways to secure the > authentication process (server-side uses the well-known endpoint > identification, client-side SSL certs are still rare, and obvious > design flaws in installed base (WinHTTP) make it difficult to > migrate to SSL client certs today. > > > So in the tradition of interoperability, I'd really like to see > a requirement for future TLS implementations with support for > gssapi-based authentication that they must offer alternative > ciphersuites (ciphersuites with traditional server-authentication > based on a Server certificate), and that these must be enabled > by default (and only be disabled if the admin explicitly configures > it that way). We will have to wiggle out the details. > > > -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 09:37: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 1HPgDV-0003v7-0p; Fri, 09 Mar 2007 09:37:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgDT-0003uz-77 for tls@ietf.org; Fri, 09 Mar 2007 09:37:07 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPgDQ-0004Wd-P3 for tls@ietf.org; Fri, 09 Mar 2007 09:37:07 -0500 Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l29EaiVp018303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2007 15:36:47 +0100 From: Simon Josefsson To: References: <20070122202751.CCBC45C01E@laser.networkresonance.com> <86mz2nr65m.fsf@raman.networkresonance.com> <87hcsulfb2.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070309:tls@ietf.org::Tde0TU8bCp9fgaFh:Xo7s X-Hashcash: 1:22:070309:pasi.eronen@nokia.com::npqWdBNgUnosJuOd:JEJC Date: Fri, 09 Mar 2007 15:36:44 +0100 In-Reply-To: (Pasi Eronen's message of "Fri\, 9 Mar 2007 16\:03\:18 +0200") Message-ID: <877itqjxfn.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.0 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.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tls@ietf.org Subject: [TLS] Re: Review of draft-santesson-tls-gssapi-00 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 writes: > Simon Josefsson wrote: >> > Here's one sketch of how this could work: >> > >> > ClientHello >> > (ciphersuite TLS_RSA_GSSAPI_WITH_AES128_CBC_SHA, >> > gss_api extension with OID list) >> >> I like this approach better, although I don't understand why you need >> special GSSAPI ciphersuites, could you explain? Wouldn't it be >> possible to do this with an extension, to enable the extra roundtrips, >> without touching the ciphersuites? > > I'm not sure if we really need special GSSAPI ciphersuites either... > But at least it would allow the client to say "I want to do > RSA+GSS-API, not plain RSA" in a way that would be correctly > understood by existing servers (that don't do GSS-API). Ok. I believe it would be a considerable advantage to avoid requiring new ciphersuites for GSS-API negotiation. >> Using gss_wrap to wrap additional information, such as channel >> bindings, has some similarities with the SASL GS2 mechanism. Note >> that it doesn't seem to work with authentication-only GSS-API >> mechanisms that doesn't support GSS_Wrap. > > Hmm... possibly it should be GSS_GetMIC instead of GSS_Wrap? > Are there any important GSS-API mechanisms that support neither? I'm working on a HMAC-SHA-256 based GSS-API mechanism that only supports authentication right now... ;-) When GSS-API mechanisms are used in protected channels (such as TLS, possibly using a double-handshake mechanism together with channel bindings in the authentication) I don't see any cryptographic need for the authentication mechanism to also provide message security services. Designing messages security services is quite complicated, so if possible I would want to avoid it. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 09:55: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 1HPgUn-00031a-MI; Fri, 09 Mar 2007 09:55:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgUn-00031Q-1F for tls@ietf.org; Fri, 09 Mar 2007 09:55:01 -0500 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 1HPgUl-0007ZQ-JX for tls@ietf.org; Fri, 09 Mar 2007 09:55:01 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l29EsmSQ013688 for ; Fri, 9 Mar 2007 16:54:55 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 16:54:47 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 16:54:47 +0200 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, 9 Mar 2007 16:54:47 +0200 Message-ID: In-Reply-To: <877itqjxfn.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdiWGwvPkRrYOCbT2aNgZumke9JrgAAF/3Q References: <20070122202751.CCBC45C01E@laser.networkresonance.com><86mz2nr65m.fsf@raman.networkresonance.com><87hcsulfb2.fsf@mocca.josefsson.org> <877itqjxfn.fsf@mocca.josefsson.org> From: To: X-OriginalArrivalTime: 09 Mar 2007 14:54:47.0485 (UTC) FILETIME=[E19956D0:01C7625A] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [TLS] RE: Review of draft-santesson-tls-gssapi-00 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: > > I'm not sure if we really need special GSSAPI ciphersuites either... > > But at least it would allow the client to say "I want to do > > RSA+GSS-API, not plain RSA" in a way that would be correctly > > understood by existing servers (that don't do GSS-API). >=20 > Ok. I believe it would be a considerable advantage to avoid=20 > requiring new ciphersuites for GSS-API negotiation. BTW, I'd be interested to know why, and what you consider to be the advantages?=20 > When GSS-API mechanisms are used in protected channels (such as=20 > TLS, possibly using a double-handshake mechanism together with=20 > channel bindings in the authentication) I don't see any=20 > cryptographic need for the authentication mechanism to also=20 > provide message security services. Designing messages security=20 > services is quite complicated, so if possible I would want to=20 > avoid it. So would your suggestion be to use the GSS-API channel binding (in GSS_Init/Accept_sec_context) instead of GSS_GetMIC/GSS_Wrap?=20 Is there any danger that this could allow replaying GSS tokens from a different context where the acceptor ignores the channel=20 bindings (see RFC 4121, Section 7)? Or can this be addressed by some other means? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 10: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 1HPgwA-0002VF-Po; Fri, 09 Mar 2007 10:23:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgw7-0002UW-Op for tls@ietf.org; Fri, 09 Mar 2007 10:23:15 -0500 Received: from c-71-198-184-110.hsd1.ca.comcast.net ([71.198.184.110] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPgw4-0004X1-3f for tls@ietf.org; Fri, 09 Mar 2007 10:23:13 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 1ACC01CC78; Fri, 9 Mar 2007 07:22:06 -0800 (PST) To: Stefan Santesson Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 References: <200703081752.SAA13445@uw1048.wdf.sap.corp> From: EKR Date: Fri, 09 Mar 2007 07:22:06 -0800 In-Reply-To: (Stefan Santesson's message of "Fri, 9 Mar 2007 14:30:51 +0000") Message-ID: <861wjyfnmp.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.8 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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 Stefan Santesson writes: > If the TLS state machine still have control over the security level of the encryption key, would it still be a problem that several roundtrips is required for the GSS exchange? Yes. > If so, why is this a problem, except from an emotional purity perspective. I'm not sure how to explain it any better than I have already. TLS has a state machine with a given number of round trips. You're proposing to change it into a state machine with an *arbitrary* numbr of round trips determined not inside TLS but rather coupled with the GSS state machine. That's a radical change and strikes me as extremely hard to analyze. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 10:26:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgyS-0004Zn-RJ; Fri, 09 Mar 2007 10:25:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgyQ-0004Zg-Pp for tls@ietf.org; Fri, 09 Mar 2007 10:25:38 -0500 Received: from c-71-198-184-110.hsd1.ca.comcast.net ([71.198.184.110] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPgyP-0005P2-At for tls@ietf.org; Fri, 09 Mar 2007 10:25:38 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 60FFE1CC78; Fri, 9 Mar 2007 07:24:36 -0800 (PST) To: Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 References: <20070122202751.CCBC45C01E@laser.networkresonance.com> <86mz2nr65m.fsf@raman.networkresonance.com> From: EKR Date: Fri, 09 Mar 2007 07:24:36 -0800 In-Reply-To: (Pasi Eronen's message of "Fri, 9 Mar 2007 12:49:11 +0200") Message-ID: <86odn2e8y3.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.8 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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 writes: > Eric Rescorla wrote: > >> >> 2) The extended roundtrips is an un-escapable consequence. If >> >> necessary I believe we can define an upper boundary of the number >> >> of roundtrips. >> >> Well, any number >2 is a radical change in the TLS state machine. > > I agree; however, there are several ways to do the roundtrips, > and some of them might be slightly less radical than the one > current proposed in draft-santesson-tls-gssapi-01. > > Here's one sketch of how this could work: > > ClientHello > (ciphersuite TLS_RSA_GSSAPI_WITH_AES128_CBC_SHA, > gss_api extension with OID list) > --------> > ServerHello > (gss_api extension with OID list) > Certificate > <-------- ServerHelloDone > ClientKeyExchange > (just like in normal RSA ciphersuites) > ChangeCipherSpec > Finished --------> > ChangeCipherSpec > <-------- Finished > > Then we'd have the GSSAPI exchange: > > ContentType=GSSAPI > ("token", gss token data) --------> > > ContentType=GSSAPI > <--- ("token", gss token data) > > (........ repeat 0..N times ..........) > > ContentType=GSSAPI > ("complete", > gss_wrap(channel binding info)) -----> > ContentType=GSSAPI > ("complete", > gss_wrap(channel binding info)) > > Application Data <-------> Application Data > > Here "channel binding info" would be something similar as in > draft-williams-on-channel-binding-01. Using a different content type > and channel binding would avoid the need to feed stuff from GSS-API > to TLS record layer/handshake layer/key calculations (which AFAIK > was one thing Eric objected to in IETF67). > > (In addition to TLS_RSA_GSSAPI_WITH_*, we could also have > TLS_DHE_GSSAPI_WITH_* ciphersuites, if we need to support > servers without a certificate.) > > Comments? So, basically, you're suggesting TLS would provide a content type for an out-of-band channel that other protocols could use for their negotiation without it winding up in the app layer? This certainly seems better than the current proposal. An alternative proposal that seems even cleaner is to simply do the GSS first and then couple it to TLS with PSK. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 10: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 1HPh65-0007TN-6A; Fri, 09 Mar 2007 10:33:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPh64-0007Rt-RU for tls@ietf.org; Fri, 09 Mar 2007 10:33:32 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPh62-00076L-Gi for tls@ietf.org; Fri, 09 Mar 2007 10:33:32 -0500 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 9 Mar 2007 15:33:29 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 9 Mar 2007 15:33:29 +0000 From: Stefan Santesson To: EKR Date: Fri, 9 Mar 2007 15:33:28 +0000 Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdiXuk81n/OybD2RraK9rNgqlMN+AAABdag Message-ID: References: <200703081752.SAA13445@uw1048.wdf.sap.corp> <861wjyfnmp.fsf@delta.rtfm.com> In-Reply-To: <861wjyfnmp.fsf@delta.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) 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 Eric, I hear what you say. I still wander why that is a problem, more than philos= ophically. I said IF, we can take security out of the picture (if we can solve that is= sue so whatever GSS-API come up with, security is preserved), what is then = the problem? Also provided that there are ways for the state machine to bail out and det= ect the end of the exchange, then what is the actual problem with that. To time consuming? To bandwidth consuming? To insecure anyway? just not pretty enough? Or something else.. It doesn't seem very radical to me to have a protocol design which allows a= n arbitrary number or roundtrips for a sub process as long as the main proc= ess can bail out/timeout gracefully. It wouldn't be the first time in proto= col design. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: EKR [mailto:ekr@networkresonance.com] > Sent: den 9 mars 2007 16:22 > To: Stefan Santesson > Cc: martin.rex@sap.com; tls@ietf.org > Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 > > Stefan Santesson writes: > > If the TLS state machine still have control over the security level > of the encryption key, would it still be a problem that several > roundtrips is required for the GSS exchange? > > Yes. > > > > If so, why is this a problem, except from an emotional purity > perspective. > > I'm not sure how to explain it any better than I have already. TLS > has a state machine with a given number of round trips. You're > proposing to change it into a state machine with an *arbitrary* > numbr of round trips determined not inside TLS but rather coupled > with the GSS state machine. That's a radical change and strikes > me as extremely hard to analyze. > > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 10:58: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 1HPhTm-0000Q0-Nv; Fri, 09 Mar 2007 10:58:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPhTk-0000LL-Pz for tls@ietf.org; Fri, 09 Mar 2007 10:58:00 -0500 Received: from c-71-198-184-110.hsd1.ca.comcast.net ([71.198.184.110] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPhTj-0002rm-GK for tls@ietf.org; Fri, 09 Mar 2007 10:58:00 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 6A7951CC78; Fri, 9 Mar 2007 07:56:58 -0800 (PST) To: Stefan Santesson Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 References: <200703081752.SAA13445@uw1048.wdf.sap.corp> <861wjyfnmp.fsf@delta.rtfm.com> From: EKR Date: Fri, 09 Mar 2007 07:56:58 -0800 In-Reply-To: (Stefan Santesson's message of "Fri, 9 Mar 2007 15:33:28 +0000") Message-ID: <86fy8ee7g5.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.8 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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 Stefan Santesson writes: > Eric, > > I hear what you say. I still wander why that is a problem, more than > philosophically. > I said IF, we can take security out of the picture (if we can solve that issue so whatever GSS-API come up with, security is preserved), what is then the problem? I've explained this as clearly as I can. Coupling two state machines is a big deal and needs careful analysis. I haven't seen any. As for taking security out of the picture, that was your claim not mine. For me, this state machine issue *is* a security issue and it's not purely an issue of establishing a key with a sufficiently strong algorithm. -Ekr > Also provided that there are ways for the state machine to bail out and detect the end of the exchange, then what is the actual problem with that. > > To time consuming? > To bandwidth consuming? > To insecure anyway? > just not pretty enough? > Or something else.. > > It doesn't seem very radical to me to have a protocol design which allows an arbitrary number or roundtrips for a sub process as long as the main process can bail out/timeout gracefully. It wouldn't be the first time in protocol design. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 13:59: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 1HPkHl-0000XQ-RX; Fri, 09 Mar 2007 13:57:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPkHk-0000XK-Ey for tls@ietf.org; Fri, 09 Mar 2007 13:57:48 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPkHj-0005VR-19 for tls@ietf.org; Fri, 09 Mar 2007 13:57:48 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA26773; Fri, 9 Mar 2007 19:57:28 +0100 (MEZ) From: Martin Rex Message-Id: <200703091852.TAA20933@uw1048.wdf.sap.corp> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 To: stefans@microsoft.com (Stefan Santesson) Date: Fri, 9 Mar 2007 19:52:22 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Mar 9, 7 02:30:51 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: b7b9551d71acde901886cc48bfc088a6 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 Stefan Santesson wrote: > > Before getting into detailed discussions on your comments, > I would like to figure out the principles of concerns and > figure out if there is any common ground we could build this on. > > As I understand you have 2 major concerns: > > 1) That the TLS state Machine has not control over the resulting > security of TLS. I.e. if a bad GSS-API mechanism is deployed, > it would degrade the security of TLS. > 2) That the GSS-API exchange requires more than 1 roundtrip > of messages to be completed. Actually, there's one more that hasn't been mentioned yet, the issue of SSL session caching&resumption, - what GSS-API based authentication means for the state in the SSL session cache - how "leaky" is the abstraction In case GSS-API authentication is hardwired into TLS (handshake) in the proposed fashion, I would like to see a requirement that the application has NO, NONE, ZERO control over the underlying GSS-API operations, i.e. no access to the credential handles, and in particular no access to the gssapi context handle. There should be no attributes&characteristics available to the application which the SSL/TLS stack does not know about from an authentication, and the SSL/TLS stack should delete the security context immediately after context establishment (or failure) and NOT retain a context handle when it completes the TLS handshake (so that there is no difference between full TLS handshake and SSL session resume). ... this might not what Microsoft is looking, and it also precludes the use of arbitrary authorization extensions. If the application caller wants to play fancy games with GSS-API and fiddle around with context handles and authorization extensions, then we should NOT put GSS-API authentication into the TLS handshake, but leave it up to the application (and the application will have to deal with persisting context attributes and things like authorization data). > > Martin suggested a method for ensuring at least TLS level security. > This has also crossed my mind but we decided not to go there initially. > But how much concern would go away if we did this in a way where at > least TLS security level is achieved? > > If the TLS state machine still have control over the security level > of the encryption key, would it still be a problem that several > roundtrips is required for the GSS exchange? I've become accustomed to GSS-API over 12 years, so personally *I* have less problems with the extra roundtrips than Eric. In some areas, TLS is IMHO more "mature" and has been more carefully analyzed and hardened than arbitrary GSS-API mechanisms. GSS-API based authentication might still have slight weaknesses that have been addressed in TLS already (countermeasures against timing attacks for decryption and padding failures). I don't think that we can "fix" those in TLS as long as GSS-API is being used for authentication, even when the handshake is done outside of TLS, e.g. like at the app-layer. In GSS-API, there is no limit on the total number of round-trips until it is determined whether authentication is successful or has failed. Performing the GSS-API handshake within TLS will undoubtedly increase the number of states in the the TLS state machine and require several additional transitions. Setting an upper limit for the number of roundtrips acceptable within the TLS handshake should be possible, but to be anywhere near useful, we need at least two full roundtrips for GSS-API, and to be on the safe side, I'd really like to see 3 full roundtrips (i.e. two additional round-trips to the regular TLS handshake). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 16:15: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 1HPmQY-0005OM-KR; Fri, 09 Mar 2007 16:15:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPmQW-0005NT-TZ for tls@ietf.org; Fri, 09 Mar 2007 16:15:00 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPmQV-0005wv-Hj for tls@ietf.org; Fri, 09 Mar 2007 16:15:00 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA08694; Fri, 9 Mar 2007 22:14:51 +0100 (MEZ) From: Martin Rex Message-Id: <200703092114.WAA24347@uw1048.wdf.sap.corp> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 To: ekr@networkresonance.com Date: Fri, 9 Mar 2007 22:14:52 +0100 (MET) In-Reply-To: <86odn2e8y3.fsf@delta.rtfm.com> from "EKR" at Mar 9, 7 07:24: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: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 EKR wrote: > > An alternative proposal that seems even cleaner is to simply > do the GSS first and then couple it to TLS with PSK. In general, you really want to do TLS first, and then (GSS-API) authentication, because there are still a lot of authentication schemes in use that are "fairly weak" and will benefit when performing the authentication exchange over an encrypted channel. It also helps to protect the client identity (from network sniffers) if the GSS-API authentication is performed within the encrypted channel. Thinking about it -- there is a Hen an Egg problem with my desire to protect the GSS-API token exchange with TLS and the attempt to XOR entropy from gssapi message protection with pre-master secret data from TLS key exchange. So I would prefer moving the GSS-API authentication handshake after the ChangeCipherSpec exchange and to look into GSS-API channel bindings to link the gssapi authentication exchange with the TLS handshake. Looking at the TLS handshake protocol, when me move the GSS-API token exchange after the clients ChangeCipherSpec message, it might be best to move it one message further, i.e. outside of the TLS handshake. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 09 18: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 1HPoUq-0006me-9V; Fri, 09 Mar 2007 18:27:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPoUp-0006i7-4R for tls@ietf.org; Fri, 09 Mar 2007 18:27:35 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPoUn-0005FG-P6 for tls@ietf.org; Fri, 09 Mar 2007 18:27:35 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id AAA12515; Sat, 10 Mar 2007 00:27:26 +0100 (MEZ) From: Martin Rex Message-Id: <200703092327.AAA27707@uw1048.wdf.sap.corp> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 To: Pasi.Eronen@nokia.com Date: Sat, 10 Mar 2007 00:27:26 +0100 (MET) In-Reply-To: from "Pasi.Eronen@nokia.com" at Mar 9, 7 12:49:11 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: d6b246023072368de71562c0ab503126 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 Pasi.Eronen@nokia.com wrote: > > Here's one sketch of how this could work: > [nice sketch deleted] > > (In addition to TLS_RSA_GSSAPI_WITH_*, we could also have > TLS_DHE_GSSAPI_WITH_* ciphersuites, if we need to support > servers without a certificate.) > > Comments? After thinking about it for a while and spreading my thought over a few postings, I have ended up exactly where you were with this sketch. :) -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Mar 10 15:35: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 1HQ8Fz-0004Df-69; Sat, 10 Mar 2007 15:33:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8Fx-0004Da-P9 for tls@ietf.org; Sat, 10 Mar 2007 15:33:33 -0500 Received: from sd-green-bigip-66.dreamhost.com ([208.97.132.66] helo=randymail-a12.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ8Fw-0001rZ-CS for tls@ietf.org; Sat, 10 Mar 2007 15:33:33 -0500 Received: from delta.rtfm.com (c-71-198-184-110.hsd1.ca.comcast.net [71.198.184.110]) by randymail-a12.g.dreamhost.com (Postfix) with ESMTP id 8C9DBA8771 for ; Sat, 10 Mar 2007 12:33:31 -0800 (PST) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 8AE681CC77 for ; Sat, 10 Mar 2007 12:32:31 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Sat, 10 Mar 2007 12:32:31 -0800 From: EKR Message-Id: <20070310203231.8AE681CC77@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Subject: [TLS] Comments on draft-nir-tee-pm-00 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 $Id: draft-nir-tee-pm-00-rev.txt,v 1.2 2007/03/10 20:44:21 ekr Exp $ This document describes a proposed mechanism for using EAP authentication with TLS. The general strategy is to do an initial TLS handshake and then once a TLS session is established send EAP payloads in the TLS handshake channel. If the EAP authentication method outputs a key that gets fed into the TLS channel keying material. Here's the picture from the draft: Client Server ------ ------ ClientHello(*) --------> ServerHello(*) (Certificate) ServerKeyExchange EapMsg(Identity-Request) <-------- ServerHelloDone ClientKeyExchange (CertificateVerify) ChangeCipherSpec InterimAuth EapMsg(Identity-Reply) --------> ChangeCipherSpec InterimAuth EapMsg(MS-CHAP-v2-Request) <-------- EapMsg(MS-CHAP-v2-Reply) --------> EapMsg(Success) <-------- Finished Finished --------> This draft seems to me to be more on the right track than the recent GSS-API draft (draft-santesson-tls-gssapi), but there are still two things that make me uncomfortable: 1. There's still a significant amount of interlocking of the EAP state machine and the TLS state machine because the Finished is delayed until EAP is Finished (though arguably the InterimAuth serves the role of the Finished). 2. The EAP key gets fed back into the TLS key. It's not clear to me why this is necessary. We need some form of channel binding but TLS is quite capable of establishing a secure session key. There's no need to mix the key back into TLS. The second is obviously easily fixed, but I think the first could be fixed as well. For instance, see Pasi Eronen't proposal for GSS of March 9. At a higher level, this is the second proposal we have before us to graft a generic authentication layer onto TLS. It seems to me that what's appropriate here is for the TLS WG to decide whether this kind of combination is appropriate and if it is to provide a single abstract mechanism which works for GSS, EAP, and whatever else people come up with. Without prejudging the conclusion that this is worth doing, as I understand it, the requirements here are threefold: 1. There needs to be a way inside of TLS to signal that you want to authenticate via EAP, GSS, etc. 2. The external authentication exchanges have to occur out-of-band from the application traffic carried over the TLS channel. 3. The external authentication needs to be cryptographically bound to the underlying TLS channel. Putting these together we get that TLS needs to provide two things: 1. An extension or cipher suite to signal you want external auth. 2. A way to carry the external auth inside TLS (e.g., a new handshake message.) In terms of the state machine, I suspect Pasi is mostly correct: do the TLS and then let the external auth protocol run. Thoughts? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Mar 10 15:37: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 1HQ8JD-0005Yg-PT; Sat, 10 Mar 2007 15:36:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ8JC-0005X7-HA for tls@ietf.org; Sat, 10 Mar 2007 15:36:54 -0500 Received: from sd-green-bigip-145.dreamhost.com ([208.97.132.145] helo=randymail-a3.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ8JB-0002X3-9D for tls@ietf.org; Sat, 10 Mar 2007 15:36:54 -0500 Received: from delta.rtfm.com (c-71-198-184-110.hsd1.ca.comcast.net [71.198.184.110]) by randymail-a3.g.dreamhost.com (Postfix) with ESMTP id A5DB2185927 for ; Sat, 10 Mar 2007 12:36:52 -0800 (PST) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id E46F51CC77 for ; Sat, 10 Mar 2007 12:35:52 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Sat, 10 Mar 2007 12:35:52 -0800 From: EKR Message-Id: <20070310203552.E46F51CC77@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [TLS] Review of draft-salowey-tls-rsa-aes-gcm-00-rev 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 $Id: draft-salowey-tls-rsa-aes-gcm-00-rev.txt,v 1.2 2007/03/10 20:47:45 ekr Exp $ This draft is needed and looks well written. I have two main comments: 1. Why limit the application to RSA? Given that the suite b document gives us GCM for ECC don't we want to provide it here for both RSA and DH? 2. We will probably want to harmonize the counter format with what was discussed in San Diego (but which I was too lame to get a new counter version out). Namely, 4 bytes of salt and 8 bytes of explicit nonce. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Mar 12 01:06: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 1HQchR-0003ru-BT; Mon, 12 Mar 2007 01:03:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQchQ-0003rp-D0 for tls@ietf.org; Mon, 12 Mar 2007 01:03:56 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQchP-0008Hp-1I for tls@ietf.org; Mon, 12 Mar 2007 01:03:56 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 11 Mar 2007 22:03:54 -0700 X-IronPort-AV: i="4.14,271,1170662400"; d="scan'208"; a="469893556:sNHT46294220" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2C53ssM026256; Sun, 11 Mar 2007 22:03:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2C53s1T000179; Mon, 12 Mar 2007 05:03:54 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 22:03:54 -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] Review of draft-salowey-tls-rsa-aes-gcm-00-rev Date: Sun, 11 Mar 2007 22:03:51 -0700 Message-ID: In-Reply-To: <20070310203552.E46F51CC77@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-salowey-tls-rsa-aes-gcm-00-rev Thread-Index: AcdjVA7cf4eQni1MQ0yxWUYgVZ1PsQBDafPQ From: "Joseph Salowey \(jsalowey\)" To: "EKR" , X-OriginalArrivalTime: 12 Mar 2007 05:03:54.0224 (UTC) FILETIME=[D50C4700:01C76463] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1303; t=1173675834; x=1174539834; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[TLS]=20Review=20of=20draft-salowey-tls-rsa-aes-gcm-0 0-rev |Sender:=20; bh=HspFMRixk/FJiofw52jNYPfoTUr9uv+gLLLtHYl4XZ0=; b=Cr3Xeg4QFUQ864jANcJdK1HdyUrE7BuKn/D+PlIFn2xd2Eg4D+xN1G1kLdKm7Y3GiqcsUfSU FKGceLOtLWI9mtfqRn9mNzMDZw+TBcSYQ1O7VQTNr30/cTOK9X5/Yr7e; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 =20 > -----Original Message----- > From: EKR [mailto:ekr@networkresonance.com]=20 > Sent: Saturday, March 10, 2007 12:36 PM > To: tls@ietf.org > Subject: [TLS] Review of draft-salowey-tls-rsa-aes-gcm-00-rev >=20 > $Id: draft-salowey-tls-rsa-aes-gcm-00-rev.txt,v 1.2=20 > 2007/03/10 20:47:45 ekr Exp $ >=20 > This draft is needed and looks well written. I have two main > comments: >=20 > 1. Why limit the application to RSA? Given that the suite b document > gives us GCM for ECC don't we want to provide it here for both > RSA and DH? [Joe] Do you mean adding static DH, anonymous DH or both to this draft? I don't see any problem adding these.=20 > 2. We will probably want to harmonize the counter format with > what was discussed in San Diego (but which I was too lame to > get a new counter version out). Namely, 4 bytes of salt=20 > and 8 bytes of explicit nonce. >=20 [Joe] Definitely, I think that is what we tried to put in the draft, I may have had some difficulties in getting this expressed. I agree the suite b draft and this draft should be in sync as much as possible.=20 >=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 Mar 12 02:17: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 1HQdox-0001Qy-PX; Mon, 12 Mar 2007 02:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQdov-0001NO-2J for tls@ietf.org; Mon, 12 Mar 2007 02:15:45 -0400 Received: from [194.29.32.68] (helo=michael.checkpoint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQdot-0007op-9N for tls@ietf.org; Mon, 12 Mar 2007 02:15:45 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l2C6FDAo017858; Mon, 12 Mar 2007 08:15:13 +0200 (IST) In-Reply-To: <20070310203231.8AE681CC77@delta.rtfm.com> References: <20070310203231.8AE681CC77@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <332985B6-96E5-4BFB-9840-65EE054D91B9@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [TLS] Comments on draft-nir-tee-pm-00 Date: Mon, 12 Mar 2007 08:15:09 +0200 To: EKR X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Thanks for the review, Eric. I hope I can address your concerns: > 1. There's still a significant amount of interlocking of the > EAP state machine and the TLS state machine because the > Finished is delayed until EAP is Finished (though arguably > the InterimAuth serves the role of the Finished). The InterimAuth does serve the role of Finished. I agree that there is no technical reason not to use a Finished message there, except to illustrate that the handshake phase is not done, and that data can not yet be sent. If it makes people more comfortable, we could call it Finished, and either use another Finished message at the end of EAP or call it ExtAuthFinished or some such. We thought that it would be cleaner to keep the current TLS behavior that application data follows the Finished message. > 2. The EAP key gets fed back into the TLS key. It's not clear > to me why this is necessary. We need some form of channel > binding but TLS is quite capable of establishing a secure > session key. There's no need to mix the key back into > TLS. This is a feature of the GSS-API draft. In our draft the EAP MSK is used only for signing the Finished message. The master secret is not changed. Hope this helps Yoav On Mar 10, 2007, at 10:32 PM, EKR wrote: > $Id: draft-nir-tee-pm-00-rev.txt,v 1.2 2007/03/10 20:44:21 ekr Exp $ > > This document describes a proposed mechanism for using EAP > authentication with TLS. The general strategy is to do an initial TLS > handshake and then once a TLS session is established send EAP payloads > in the TLS handshake channel. If the EAP authentication method outputs > a key that gets fed into the TLS channel keying material. Here's > the picture from the draft: > > > Client Server > ------ ------ > > ClientHello(*) --------> > ServerHello(*) > (Certificate) > ServerKeyExchange > EapMsg(Identity-Request) > <-------- ServerHelloDone > ClientKeyExchange > (CertificateVerify) > ChangeCipherSpec > InterimAuth > EapMsg(Identity-Reply) --------> > ChangeCipherSpec > InterimAuth > EapMsg(MS-CHAP-v2-Request) > <-------- > EapMsg(MS-CHAP-v2-Reply) --------> > EapMsg(Success) > <-------- Finished > Finished --------> > > This draft seems to me to be more on the right track than the > recent GSS-API draft (draft-santesson-tls-gssapi), but there are > still two things that make me uncomfortable: > > 1. There's still a significant amount of interlocking of the > EAP state machine and the TLS state machine because the > Finished is delayed until EAP is Finished (though arguably > the InterimAuth serves the role of the Finished). > 2. The EAP key gets fed back into the TLS key. It's not clear > to me why this is necessary. We need some form of channel > binding but TLS is quite capable of establishing a secure > session key. There's no need to mix the key back into > TLS. > > The second is obviously easily fixed, but I think the first could > be fixed as well. For instance, see Pasi Eronen't proposal for > GSS of March 9. > > > At a higher level, this is the second proposal we have before us to > graft a generic authentication layer onto TLS. It seems to me that > what's appropriate here is for the TLS WG to decide whether this kind > of combination is appropriate and if it is to provide a single > abstract mechanism which works for GSS, EAP, and whatever else people > come up with. > > > Without prejudging the conclusion that this is worth doing, > as I understand it, the requirements here are threefold: > > 1. There needs to be a way inside of TLS to signal that you want > to authenticate via EAP, GSS, etc. > 2. The external authentication exchanges have to occur out-of-band > from the application traffic carried over the TLS channel. > 3. The external authentication needs to be cryptographically bound > to the underlying TLS channel. > > Putting these together we get that TLS needs to provide two things: > > 1. An extension or cipher suite to signal you want external auth. > 2. A way to carry the external auth inside TLS (e.g., a new handshake > message.) > > In terms of the state machine, I suspect Pasi is mostly correct: do > the TLS and then let the external auth protocol run. > > Thoughts? > > _______________________________________________ > 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 Mar 12 02:17: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 1HQdp7-0001Yq-7F; Mon, 12 Mar 2007 02:15:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQdp6-0001WL-2Y for tls@ietf.org; Mon, 12 Mar 2007 02:15:56 -0400 Received: from mailbigip.dreamhost.com ([208.97.132.5] helo=randymail-a8.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQdp4-00089X-Q6 for tls@ietf.org; Mon, 12 Mar 2007 02:15:56 -0400 Received: from delta.rtfm.com (c-71-198-184-110.hsd1.ca.comcast.net [71.198.184.110]) by randymail-a8.g.dreamhost.com (Postfix) with ESMTP id 1458AAF512; Sun, 11 Mar 2007 23:15:52 -0700 (PDT) Received: by delta.rtfm.com (Postfix, from userid 1001) id 72B791CC2D; Sun, 11 Mar 2007 23:14:53 -0700 (PDT) To: "Joseph Salowey (jsalowey)" Subject: Re: [TLS] Review of draft-salowey-tls-rsa-aes-gcm-00-rev References: From: EKR Date: Sun, 11 Mar 2007 23:14:53 -0700 In-Reply-To: (Joseph Salowey's message of "Sun, 11 Mar 2007 22:03:51 -0700") Message-ID: <864por9eea.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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 "Joseph Salowey \(jsalowey\)" writes: > > >> -----Original Message----- >> From: EKR [mailto:ekr@networkresonance.com] >> Sent: Saturday, March 10, 2007 12:36 PM >> To: tls@ietf.org >> Subject: [TLS] Review of draft-salowey-tls-rsa-aes-gcm-00-rev >> >> $Id: draft-salowey-tls-rsa-aes-gcm-00-rev.txt,v 1.2 >> 2007/03/10 20:47:45 ekr Exp $ >> >> This draft is needed and looks well written. I have two main >> comments: >> >> 1. Why limit the application to RSA? Given that the suite b document >> gives us GCM for ECC don't we want to provide it here for both >> RSA and DH? > [Joe] Do you mean adding static DH, anonymous DH or both to this draft? > I don't see any problem adding these. I would think RSA/DSS-DHE? >> 2. We will probably want to harmonize the counter format with >> what was discussed in San Diego (but which I was too lame to >> get a new counter version out). Namely, 4 bytes of salt >> and 8 bytes of explicit nonce. >> > [Joe] Definitely, I think that is what we tried to put in the draft, I > may have had some difficulties in getting this expressed. I agree the > suite b draft and this draft should be in sync as much as possible. Yeah, the suite b has changed but not been posted yet :( I'll let you know when I get it fixed. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Mar 12 05:42: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 1HQh1X-0008AF-Li; Mon, 12 Mar 2007 05:40:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQh1V-0008A3-O3 for tls@ietf.org; Mon, 12 Mar 2007 05:40:57 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQh1U-0007j7-8L for tls@ietf.org; Mon, 12 Mar 2007 05:40:57 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2C9ePcs031329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2007 10:40:25 +0100 From: Simon Josefsson To: EKR References: <20070310203231.8AE681CC77@delta.rtfm.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070312:tls@ietf.org::OZ5cB0FCIVzeB7E5:3QKA X-Hashcash: 1:22:070312:ekr@networkresonance.com::BQUqneBh04dxdCGE:ZY2l Date: Mon, 12 Mar 2007 10:40:25 +0100 In-Reply-To: <20070310203231.8AE681CC77@delta.rtfm.com> (ekr@networkresonance.com's message of "Sat\, 10 Mar 2007 12\:32\:31 -0800") Message-ID: <87y7m2iyuu.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.7 required=4.0 tests=AWL,BAYES_50, 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.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tls@ietf.org Subject: [TLS] Re: Comments on draft-nir-tee-pm-00 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 EKR writes: > At a higher level, this is the second proposal we have before us to > graft a generic authentication layer onto TLS. It seems to me that > what's appropriate here is for the TLS WG to decide whether this kind > of combination is appropriate and if it is to provide a single > abstract mechanism which works for GSS, EAP, and whatever else people > come up with. I believe it would be useful to work on this. There has been several authentication protocols that use TLS internally; incidentally I've authored both EAP and SASL mechanisms that do this. I believe there would be better interop and better security if those authentication mechanisms could start TLS and then negotiate the authentication mechanism inside TLS. > Without prejudging the conclusion that this is worth doing, > as I understand it, the requirements here are threefold: > > 1. There needs to be a way inside of TLS to signal that you want > to authenticate via EAP, GSS, etc. > 2. The external authentication exchanges have to occur out-of-band > from the application traffic carried over the TLS channel. > 3. The external authentication needs to be cryptographically bound > to the underlying TLS channel. That seems to be a good summary. Here is a "nice property": 4. The mechanism should permit the double-handshake capability of TLS, to further protect the authentication step. There are several weak authentication mechanisms (including CRAM-MD5 and MS-CHAP) that could be enhanced by being done under TLS. I believe that there is considerable deployment of CRAM-MD5 and MSCHAP that it is easier to protect those installations instead of replacing them, at least in the short run. Negotiation them inside TLS is one way to protect them. If a solution to that problem coincide with a solution that is good in the long run too, all the better. > Putting these together we get that TLS needs to provide two things: > > 1. An extension or cipher suite to signal you want external auth. > 2. A way to carry the external auth inside TLS (e.g., a new handshake > message.) > > In terms of the state machine, I suspect Pasi is mostly correct: do > the TLS and then let the external auth protocol run. We already have one TLS extension defined and deployed that seem to fit these requirements: the TLS Inner Application extension: http://tools.ietf.org/wg/tls/draft-funk-tls-inner-application-extension-03.txt I believe it could support GSS-API too. After implementing it, I don't think it fits well with the TLS model -- IIRC it violates the TLS extension mechanism for resume operations -- and some careful review is necessary to make sure it fits within the GSS-API model too. The chose to re-use RADIUS/Diameter AVP's may also be sub-optimal for non-EAP uses. I wouldn't argue that we should use TLS/IA, but we can surely learn from the design and improve it. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Mar 12 06:09: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 1HQhRq-0001b2-Df; Mon, 12 Mar 2007 06:08:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQhRo-0001ap-DW for tls@ietf.org; Mon, 12 Mar 2007 06:08:08 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQhRm-0002VW-Nt for tls@ietf.org; Mon, 12 Mar 2007 06:08:08 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2CA7ou3003491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2007 11:07:54 +0100 From: Simon Josefsson To: References: <20070122202751.CCBC45C01E@laser.networkresonance.com> <86mz2nr65m.fsf@raman.networkresonance.com> <87hcsulfb2.fsf@mocca.josefsson.org> <877itqjxfn.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070312:pasi.eronen@nokia.com::R5uvtCecbcE6Hrb6:ARD X-Hashcash: 1:22:070312:tls@ietf.org::cWJyFUmd7PZErQM+:4eHO Date: Mon, 12 Mar 2007 11:07:49 +0100 In-Reply-To: (Pasi Eronen's message of "Fri\, 9 Mar 2007 16\:54\:47 +0200") Message-ID: <87tzwqixl6.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.7 required=4.0 tests=AWL,BAYES_50, 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.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: tls@ietf.org Subject: [TLS] Re: Review of draft-santesson-tls-gssapi-00 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 writes: > Simon Josefsson wrote: > >> > I'm not sure if we really need special GSSAPI ciphersuites either... >> > But at least it would allow the client to say "I want to do >> > RSA+GSS-API, not plain RSA" in a way that would be correctly >> > understood by existing servers (that don't do GSS-API). >> >> Ok. I believe it would be a considerable advantage to avoid >> requiring new ciphersuites for GSS-API negotiation. > > BTW, I'd be interested to know why, and what you consider > to be the advantages? That's a good question... since this was my gut reaction, I'm not sure if I can put words on it easily, but I suspect that some of the reason includes variations of these concerns: 1) Adding an extension for GSS-API works with all ciphersuites, and makes the use of GSS-API orthogonal to the ciphersuite used. That makes it possible to define, e.g., a new public-key algorithm in TLS and have existing extensions, such as a GSS-API or EAP extensions, apply to it directly. 2) Let's say we create new ciphersuites for both GSS-API and EAP. What's saying that someone don't want to use both GSS-API and EAP at the same time? Should there be TLS_RSA_WITH_AES128_CBC_SHA_GSSAPI_EAP ciphersuites? What about if SASL authentication is also supported? If GSS-API, EAP, and possibly SASL, were negotiated as a separate (or possibly the same) TLS extension, this would not be a problem. At least if the design of the extension(s) were done properly. 3) Simplify TLS analysis. If GSS-API or EAP is tightly mixed into the TLS protocol, e.g. the TLS state machine, it becomes harder to analyse TLS for correctness. If we can prove that TLS with the extension mechanism is secure today, that analysis would hold for TLS + GSS-API too. 4) Simplify implementations. At least in GnuTLS, adding a new TLS extension is simple, and it doesn't have much effect on the core part of the library. It thus leads to more easily modularized code. Adding a new ciphersuite is not as easy to modularize. > >> When GSS-API mechanisms are used in protected channels (such as >> TLS, possibly using a double-handshake mechanism together with >> channel bindings in the authentication) I don't see any >> cryptographic need for the authentication mechanism to also >> provide message security services. Designing messages security >> services is quite complicated, so if possible I would want to >> avoid it. > > So would your suggestion be to use the GSS-API channel binding > (in GSS_Init/Accept_sec_context) instead of GSS_GetMIC/GSS_Wrap? Perhaps. Some more thinking on this choice may be useful. One problem with this approach is that if the GSS-API channel binding negotiation fails, for some reason, the implementation typically doesn't know that the cause was the failed channel binding. That was a concern in the SASL GS2 mechanism, where one peer may set a channel bindings that refer to a security channel that the other end does not know about. For example, your MUA might not be aware of a IPSEC channel, and thus might not be able to set the correct IPSEC channel binding. Therefor, we chose to use GSS_Wrap instead of GSS_Init_sec_context channel binding concept, with a fallback to an identity function if the GSS-API mechanism did not support GSS_Wrap. (And yes, the fallback open up for a MITM vulnerability, but other people in the SASL WG thought this was acceptable, possibly reasoning that the GSS-API mechanism was already too weak to provide anything better. Which may be reasonable, although it leads to complexity.) I don't think this needs to be a concern for TLS though. If the GSS-API channel binding fails, things probably should fail. > Is there any danger that this could allow replaying GSS tokens > from a different context where the acceptor ignores the channel > bindings (see RFC 4121, Section 7)? Or can this be addressed > by some other means? Yes, I think there are such concerns. Further, I suspect there are GSS-API mechanisms out there that ignore the channel binding field, but I'll let those with more experience from non-standard GSS-API mechanism fill in the details here. Since this is often only a problem with particular GSS-API mechanisms, one could leave this as a security consideration: 'This TLS GSS-API extension assumes that the negotiated GSS-API mechanism use the channel binding data properly, which at least includes that authentication cannot succeed without both ends supplying the same channel binding, and that successful replay of the tokens is not possible.' /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Mar 12 12:16: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 1HQnBA-0003DF-2M; Mon, 12 Mar 2007 12:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnB8-0003Ck-GN for tls@ietf.org; Mon, 12 Mar 2007 12:15:18 -0400 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQnB2-0004kg-VX for tls@ietf.org; Mon, 12 Mar 2007 12:15:18 -0400 Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 12 Mar 2007 16:14:58 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Mon, 12 Mar 2007 16:14:57 +0000 From: Stefan Santesson To: EKR Date: Mon, 12 Mar 2007 16:14:49 +0000 Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdiY7lJoKRQ2U67QoOjcWIzSPZdQgCWjgAw Message-ID: References: <200703081752.SAA13445@uw1048.wdf.sap.corp> <861wjyfnmp.fsf@delta.rtfm.com> <86fy8ee7g5.fsf@delta.rtfm.com> In-Reply-To: <86fy8ee7g5.fsf@delta.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.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 Eric, I'm sorry, but I need more information to understand your concern. > As for taking security out of the picture, that was your claim not > mine. For me, this state machine issue *is* a security issue and > it's not purely an issue of establishing a key with a sufficiently > strong algorithm. What other security issue than the strength of the key is there? TLS does not require any user authentication, so any added technology here = can only be positive if the alternative in anonymous. Regarding key strength, I think all cryptographic experts would agree that: Good key XOR bad key =3D good key At least if they are produced independent of each other, e.g. that the bad = key is not actively selected with knowledge of the good key to cancel it or= make it bad. Following this logic, you can safely have another process creating a key of= un-known strength and XOR it with the "good" key of TLS, and preserve the = security level of TLS. This simple assumption, makes the security impact very easy to analyze with= respect to cryptographic strength. > I've explained this as clearly as I can. Coupling two state machines > is a big deal and needs careful analysis. I haven't seen any. First I don't see them really as coupled. They are performing independent o= f each other with respect to the information exchange. So we have one proto= col that allows another protocol exchange inside it. That is not very uncom= mon. The coupling comes only in terms of some resulting information being handed= over to the TLS state machine upon completion of the sub process. I represent a vendor that is interested to do just this, and see no problem= with it. So yes, it would help a great deal to understand why this is a "big deal". = Maybe we missed something, or maybe this isn't that big of a problem If it would not turn out to be a big deal, we have a significant win here b= y allowing numerous non-PKI based authentication technologies to be used wi= th TLS. That is a "big deal". Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: EKR [mailto:ekr@networkresonance.com] > Sent: den 9 mars 2007 16:57 > To: Stefan Santesson > Cc: martin.rex@sap.com; tls@ietf.org > Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 > > Stefan Santesson writes: > > > Eric, > > > > I hear what you say. I still wander why that is a problem, more than > > philosophically. > > I said IF, we can take security out of the picture (if we can solve > that issue so whatever GSS-API come up with, security is preserved), > what is then the problem? > > I've explained this as clearly as I can. Coupling two state machines > is a big deal and needs careful analysis. I haven't seen any. > > As for taking security out of the picture, that was your claim not > mine. For me, this state machine issue *is* a security issue and > it's not purely an issue of establishing a key with a sufficiently > strong algorithm. > > -Ekr > > > > > Also provided that there are ways for the state machine to bail out > and detect the end of the exchange, then what is the actual problem > with that. > > > > To time consuming? > > To bandwidth consuming? > > To insecure anyway? > > just not pretty enough? > > Or something else.. > > > > It doesn't seem very radical to me to have a protocol design which > allows an arbitrary number or roundtrips for a sub process as long as > the main process can bail out/timeout gracefully. It wouldn't be the > first time in protocol design. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Mar 12 12:21: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 1HQnGn-0004tq-B1; Mon, 12 Mar 2007 12:21:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnGl-0004tj-D2 for tls@ietf.org; Mon, 12 Mar 2007 12:21:07 -0400 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQnGf-0005NM-8h for tls@ietf.org; Mon, 12 Mar 2007 12:21:07 -0400 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 12 Mar 2007 16:21:00 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Mon, 12 Mar 2007 16:20:58 +0000 From: Stefan Santesson To: EKR , "Pasi.Eronen@nokia.com" Date: Mon, 12 Mar 2007 16:20:49 +0000 Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdiX0SBS7Cr6696RXanIPgS688y5ACYoDkw Message-ID: References: <20070122202751.CCBC45C01E@laser.networkresonance.com> <86mz2nr65m.fsf@raman.networkresonance.com> <86odn2e8y3.fsf@delta.rtfm.com> In-Reply-To: <86odn2e8y3.fsf@delta.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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, Thanks for this interesting proposal. Let me clarify that I'm personally in no way locked on the current proposal= in term of selected architecture. As long as we can achieve the same goal. Your proposal is interesting as an alternative that we definitely should co= nsider. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: EKR [mailto:ekr@networkresonance.com] > Sent: den 9 mars 2007 16:25 > To: Pasi.Eronen@nokia.com > Cc: tls@ietf.org > Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 > > writes: > > > Eric Rescorla wrote: > > > >> >> 2) The extended roundtrips is an un-escapable consequence. If > >> >> necessary I believe we can define an upper boundary of the number > >> >> of roundtrips. > >> > >> Well, any number >2 is a radical change in the TLS state machine. > > > > I agree; however, there are several ways to do the roundtrips, > > and some of them might be slightly less radical than the one > > current proposed in draft-santesson-tls-gssapi-01. > > > > Here's one sketch of how this could work: > > > > ClientHello > > (ciphersuite TLS_RSA_GSSAPI_WITH_AES128_CBC_SHA, > > gss_api extension with OID list) > > --------> > > ServerHello > > (gss_api extension with OID list) > > Certificate > > <-------- ServerHelloDone > > ClientKeyExchange > > (just like in normal RSA ciphersuites) > > ChangeCipherSpec > > Finished --------> > > ChangeCipherSpec > > <-------- Finished > > > > Then we'd have the GSSAPI exchange: > > > > ContentType=3DGSSAPI > > ("token", gss token data) --------> > > > > ContentType=3DGSSAPI > > <--- ("token", gss token data) > > > > (........ repeat 0..N times ..........) > > > > ContentType=3DGSSAPI > > ("complete", > > gss_wrap(channel binding info)) -----> > > ContentType=3DGSSAPI > > ("complete", > > gss_wrap(channel binding info)) > > > > Application Data <-------> Application Data > > > > Here "channel binding info" would be something similar as in > > draft-williams-on-channel-binding-01. Using a different content type > > and channel binding would avoid the need to feed stuff from GSS-API > > to TLS record layer/handshake layer/key calculations (which AFAIK > > was one thing Eric objected to in IETF67). > > > > (In addition to TLS_RSA_GSSAPI_WITH_*, we could also have > > TLS_DHE_GSSAPI_WITH_* ciphersuites, if we need to support > > servers without a certificate.) > > > > Comments? > > So, basically, you're suggesting TLS would provide a content type > for an out-of-band channel that other protocols could use for their > negotiation without it winding up in the app layer? This certainly > seems better than the current proposal. > > An alternative proposal that seems even cleaner is to simply > do the GSS first and then couple it to TLS with PSK. > > -Ekr > > > _______________________________________________ > 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 Mar 16 13:27: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 1HSGA0-0002ck-5o; Fri, 16 Mar 2007 13:24:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSG9y-0002ce-Rb for tls@ietf.org; Fri, 16 Mar 2007 13:24:10 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSG9x-0003SD-Hm for tls@ietf.org; Fri, 16 Mar 2007 13:24:10 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 791A12EF for ; Fri, 16 Mar 2007 13:24:08 -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 1461535831 for ; Fri, 16 Mar 2007 13:24:07 -0400 (EDT) Message-ID: <45FAD290.2040401@pobox.com> Date: Fri, 16 Mar 2007 10:23:28 -0700 From: Mike User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] TLS 1.2 and hash agility for signatures 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: cd26b070c2577ac175cd3a6d878c6248 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 > There's one area in TLS 1.2 that still doesn't give me a warm > fuzzy feeling that "yes, this is the way it should be done", and > that's the algorithm agility for signatures (in certificates and > ClientKeyExchange/ServerKeyExchange messages). > > I'd like to get some more discussion about this, and fresh > ideas on what's the best way to implement it in TLS 1.2. > > Some issues that don't yet seem right: > > 1) Asymmetry: The server sends its list of supported hashes in the > CertificateRequest message, together with list of trusted CAs (DNs) > and ClientCertificateTypes. The client sends the list of supported > hashes in cert_hash_types extension, list of trusted CAs (DNs or > hashes) in trusted_ca_keys extension, and there's no equivalent of > ClientCertificateType. In addition, we have the "cert_type" extension > for non-X.509 certs (draft-ietf-tls-openpgp-keys). If you want to make this symmetrical and have the server send this information in extensions, then it is up to the client to send the extensions in its ClientHello since the server can't send them without being requested. Leaving it in the CertificateRequest message takes the client out of the picture since the format of the message dictates what information must be present. > To make things worse, ClientCertificateTypes field seems quite > redundant, since at this point we already know the ciphersuite, and > that limits our choice (it doesn't make sense to request dss_sign > certificate if you've already negotiated RSA ciphersuite). Or if it's > not redundant, then we need more text in the spec explaining why not. I think it's perfectly OK to negotiate an RSA ciphersuite and then ask for either an RSA or DSS client certificate. The client cert is only used for authenticating the client, so it doesn't need to match the server's certificate. > 2) Wrong concept: instead of telling what hash algorithms we support > we'd really like to tell what kinds of signatures we can verify. > E.g. for RSA, we have at least three different schemes (PKCS#1 v1.5, > PSS and ANSI X9.32), all of which can be used with different hashes. > And we also have DSS and ECDSA. > > For TLS level signatures (ServerKeyExchange/CertificateVerify), some > part of this is already determined by the ciphersuite's key exchange > algorithm (e.g. RSA here means PKCS#1 v1.5; if someone wants to use > RSA PSS we'd define new ciphersuites). But for certificates, the > situation is not the same; we could have certificate containing RSA > public key signed with DSS, or something. > > Should we have signature_schemes extension instead of cert_hash_types? > (with values like rsa_pkcs15_sha256, dss_sha1, ecdsa_sha512, etc.) > Or separate lists for certificate signatures and signatures in TLS? I think that signature_schemes is better than cert_hash_types. In my code, that is what I implemented anyway. One problem I encountered is if SHA-1 is specified, you need to look for either an RSA or DSS certificate, but maybe only RSA is desired -- there is no way to say that. With signature_schemes, you get to ask for exactly what you want. > 3) Tying algorithm in ServerKeyExchange/CertificateVerify and > certificate. The current spec says that for RSA, signatures in TLS > (ServerKeyExchange and CertificateVerify) use the same hash as was > used by the CA in the certificate. > > The idea itself is not wrong: if you're worried about using SHA-1, > then it's much more important to use something better in certificates > (usually long-lived) than in ServerKeyExchange/CertificateVerify > (which include fresh nonces, and are verified only once immediately > following signature generation -- so offline attacks don't count). > > However... what if the cert isn't signed with RSA? Or it's signed with > RSA PSS? And is it OK to require the peer to parse its own certificate > (something not previously required)? Perhaps we should decouple these? Just throwing out an idea, you could use the hash algorithm specified by the cipher suite (same as used by HMAC). Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Mar 17 13:33: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 1HScjf-0001lJ-Qv; Sat, 17 Mar 2007 13:30:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HScje-0001lE-OP for tls@ietf.org; Sat, 17 Mar 2007 13:30:30 -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 1HScjb-0006RC-5P for tls@ietf.org; Sat, 17 Mar 2007 13:30:30 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2HHU69n002129; Sat, 17 Mar 2007 19:30:21 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Mar 2007 19:28:22 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Mar 2007 19:28:21 +0200 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] TLS 1.2 and hash agility for signatures Date: Sat, 17 Mar 2007 19:28:45 +0200 Message-ID: In-Reply-To: <20070306143001.GA19204@tau.invalid> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS 1.2 and hash agility for signatures Thread-Index: Acdf+/Co0oeMiUAATLSQ7woAuVSoGAIvTeOQ References: <20070306143001.GA19204@tau.invalid> From: To: X-OriginalArrivalTime: 17 Mar 2007 17:28:21.0884 (UTC) FILETIME=[A91D0BC0:01C768B9] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070317193021-0786CBB0-5F4C7126/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 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 Hi Bodo, And thanks for a detailed reply! I had overlooked the fact that TLS indeed does not require the *client* certificate's algorithm to match the cipher suite. Regarding the Signature structure (in ServerKeyExchange and CertificateVerify), I agree that we probably need to include a field that tells which hash algorithm was used. In RSASSA-PKCS1-v1_5, the signature itself includes the algorithm identifier, but this is not the case for DSA (or ECDSA, for what matter)... so if the certificate does not specify a single unique allowed algorithm, we need to tell which was used in TLS. Given that some signature algorithms have more tweakable parameters than just the hash algorithm (e.g. PSS has salt length, MGF and the MGF's hash algorithm), perhaps the simplest solution would be just to use DER-encoded AlgorithmIdentifier structures (instead of defining a new IANA-maintained number space just for TLS)?=20 (Of course, a sane implementation probably wouldn't include a=20 DER encoder/decoder, but just list of octet strings for things it supports; e.g. 0x3021300906052b0e03021a05000414 for RSASSA-PKCS1-v1_5 with SHA-1.) If we use the AlgorithmIdentifier structure in the Signature, would that also work for the cert_hash_types extension? (Which, as you point, could be really called "signature_hash_types"=20 since it also covers signatures outside certs.) Comments? Best regards, Pasi=20 > -----Original Message----- > From: ext Bodo Moeller [mailto:bmoeller@acm.org]=20 > Sent: 06 March, 2007 16:30 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: tls@ietf.org > Subject: Re: [TLS] TLS 1.2 and hash agility for signatures >=20 > On Tue, Mar 06, 2007 at 01:01:42PM +0200, Pasi.Eronen@nokia.com wrote: >=20 > > There's one area in TLS 1.2 that still doesn't give me a warm=20 > > fuzzy feeling that "yes, this is the way it should be done", and=20 > > that's the algorithm agility for signatures (in certificates and > > ClientKeyExchange/ServerKeyExchange messages). > >=20 > > I'd like to get some more discussion about this, and fresh > > ideas on what's the best way to implement it in TLS 1.2. > >=20 > > Some issues that don't yet seem right: > >=20 > >=20 > > 1) Asymmetry: The server sends its list of supported hashes in the > > CertificateRequest message, together with list of trusted CAs (DNs) > > and ClientCertificateTypes. The client sends the list of supported > > hashes in cert_hash_types extension, list of trusted CAs (DNs or > > hashes) in trusted_ca_keys extension, and there's no equivalent of > > ClientCertificateType. In addition, we have the=20 > "cert_type" extension > > for non-X.509 certs (draft-ietf-tls-openpgp-keys). > >=20 > > To make things worse, ClientCertificateTypes field seems quite > > redundant, since at this point we already know the ciphersuite, and > > that limits our choice (it doesn't make sense to request dss_sign > > certificate if you've already negotiated RSA ciphersuite).=20 > Or if it's > > not redundant, then we need more text in the spec=20 > explaining why not. >=20 > I don't think that there's anything wrong with using a DSA certificate > in an RSA ciphersuite. The only cases where symmetry is required are > the fixed_dh certificate types (and, similarly, the fixed_ecdh > certificate types from RFC 4492), since in these the client > certificate is tied to the actual key exchange and client > authentication does not use the separate CertificateVerify message. >=20 > If both the client and the server support all of RSA and DSA and > ECDSA, then it might just happen to be the case that the server has an > RSA certificate, say, while the client has an ECDSA certificate. So > you might see an RSA ciphersuite in the handshake, but the client > would still use ECDSA in the CertificateVerify. (This scenario can > make quite a lot of sense in certain configurations: RSA signature > verification and RSA encryption are usually very easy to do for the > client, but ECDSA signing might be much faster than RSA signing.) >=20 > So it's quite useful if the server can indicate to the client what > kinds of signatures it can verify. >=20 >=20 >=20 > > Perhaps we can't avoid this asymmetry completely, but is=20 > there any way > > to make this a bit nicer? Perhaps remove the ClientCertificateTypes > > field in TLS 1.2, and use cert_hash_types extension also from server > > to client? > >=20 > >=20 > > 2) Wrong concept: instead of telling what hash algorithms we support > > we'd really like to tell what kinds of signatures we can verify. > > E.g. for RSA, we have at least three different schemes (PKCS#1 v1.5, > > PSS and ANSI X9.32), all of which can be used with different hashes. > > And we also have DSS and ECDSA. > >=20 > > For TLS level signatures (ServerKeyExchange/CertificateVerify), some > > part of this is already determined by the ciphersuite's key exchange > > algorithm (e.g. RSA here means PKCS#1 v1.5; if someone wants to use > > RSA PSS we'd define new ciphersuites). But for certificates, the > > situation is not the same; we could have certificate containing RSA > > public key signed with DSS, or something. > >=20 > > Should we have signature_schemes extension instead of=20 > cert_hash_types? > > (with values like rsa_pkcs15_sha256, dss_sha1, ecdsa_sha512, etc.) =20 > > Or separate lists for certificate signatures and signatures in TLS? >=20 > I don't think that there's anything basically wrong with using > ClientCertificateType. The list of ClientCertificateType values alone > doesn't provide complete information since RSA might mean RSA PKCS#1 > v1.5 with a limited selection of hash algorithms only, or might allow > much more flexibility. Adding a list of HashType values, as you point > out, doesn't quite address this issue since there are more aspects > that can be varied than just the choice of hash algorithm. (Also, > sometimes, different choices of hash algorithms might be available > with different signature algorithms.) Also often (but not always) > it's the complete certificate chain that must be considered, i.e. not > just the CertificateVerify signature but additionally each and every > signature in the client's certificate chain up to some anchor that the > server is willing to rely on for verification purposes. (Sometimes > the server might not need to validate the actual certificate chain, if > permissible client certificates have been made available for direct > verification without the computational overhead of a PKI.) >=20 >=20 > So things can be quite complicated. I don't think, though, that we > really have to solve all of this in the TLS specification! >=20 > In practice, the most important part of the CertificateRequest message > is certificate_authorities, the list of distinguished names of > acceptable CAs. If the client happens to pick a certificate using a > chain for which the server does not have an appropriate anchor, then > it does not matter at all if the server can handle the hash algorithm > (or even the signature algorithm) used by the client for the > CertificateVerify or not -- either way the server won't be able to use > the signature. But if the client has a certificate signed by a CA > that the server is willing to rely on, then generally that CA's > policies will determine what signature algorithms (with what hash > algortihms, etc.) can be encountered in certificate chains. This is > usually enough since, for obvious pragmatic reasons, CAs don't tend to > mix lots of different techniques in their certificate chains. (It's > similar for the use of the signing key in the client's end-entity > certificate -- for the case of RSA, the TLS 1.2 draft quite > reasonably, yet somewhat problematically [see below], says that "the > same function (denoted Hash) must be used as was used to create the > signature for the client's certificate".) >=20 > So we could spend a lot of time on coming up with a detailed solutions > allowing a find-grained negotiation of signing algorithm details, but > I think we don't really have to do that. Reality always could be more > complicated than what we foresee (a complete solution would, for > example, have to provide the server with means to specify the X.509 > extensions that it can parse, lest the client use a certificate chain > that has to be rejected due to an unknown critical extension). In > practice, a rather simple solution should work very well. >=20 >=20 > The list of ClientCertificateType values in the CertificateRequest may > be a useful hint. Besides, it is very brief, and we've always had > this in the protocol; so there's no reason to throw this out. Maybe > adding a list of HashType values (as the TLS 1.2 draft does) is > reasonable too, but I don't really see compelling reasons to do so. > An optional TLS extension mirroring the client's Cert Hash Types > extension would look quite appropriate to me (why use a different tool > for server-to-client communcation than for client-to-server > communication?) -- also to be interpreted as a hint, not a complete > specification of what the server can handle. >=20 > I don't really think we need signature_schemes in place of > cert_hash_types. The rsa_sign client certificate type currently is > restricted to RSA PKCS#1 v1.5 signatures, and if there was demand to > use PSS, say, a separate client certificate type for RSA-PSS would be > reasonable. But then in practice, a demand for PSS would probably > mean separate PKIs with end-entity certificates intended for PSS > signing anyway (it would be rather silly to use a single RSA key both > for PKCS#1 v1.5 and PSS signing), so maybe we shouldn't worry about > this too much. >=20 >=20 >=20 > > 3) Tying algorithm in ServerKeyExchange/CertificateVerify and > > certificate. The current spec says that for RSA, signatures in TLS > > (ServerKeyExchange and CertificateVerify) use the same hash as was > > used by the CA in the certificate. > >=20 > > The idea itself is not wrong: if you're worried about using SHA-1, > > then it's much more important to use something better in=20 > certificates > > (usually long-lived) than in ServerKeyExchange/CertificateVerify > > (which include fresh nonces, and are verified only once immediately > > following signature generation -- so offline attacks don't count). > >=20 > > However... what if the cert isn't signed with RSA? Or it's=20 > signed with > > RSA PSS? And is it OK to require the peer to parse its own=20 > certificate > > (something not previously required)? Perhaps we should=20 > decouple these? >=20 > Well, the client wouldn't really have to actively parse its own > certificate, just know what's in there. That's additional data, just > like the secret key matching the certificate's public key is > additional data. >=20 > Arguably, the TLS specification should not make such strict rules for > the hash algorithm to be used during signing, though, because it's > very reasonable to assume that the client's end-entity certificate > would completely specify the client's signing algorithm, including the > hash algorithm to be used. And this might not match the hash > algorithm used by the CA while signing the respective certificate, so > the rule in the TLS 1.2 draft might be incompatible with keys that > otherwise would be absolutely acceptable for use. (E.g., the CA might > have a 4096-bit RSA key and use a 256-bit hash for certificates, but > issue certificates on 2048-bit keys intended for use with 224-bit > hashes.) The algorithm given in SubjectPublicKey might be more > explicit than just an unspecific "rsaEncryption" and might fix the > hash algorithm; and even if the SubjectPublicKey does not reveal it, > the hash algorithm might be fixed. >=20 >=20 >=20 > > 4) RSA-specific text. It looks like much of the text (and whole > > cert_hash_types) is really specific to RSA ciphersuites, since the > > spec fixes SHA-1 for DSS, and RFC4492 specifies that for ECDSA, the > > hash is always SHA-1 unless otherwise specified by yet-unspecified > > extension in the certificate. > >=20 > > It may not be possible to avoid RSA-specific text, but then=20 > it should > > be easy to see what parts are specific to RSA and what are=20 > not. And we > > should probably plan for hash agility in DSS as well? >=20 > Yes, limiting DSA to SHA-1 quite obviously has historic reasons -- or > qrather, reasons that hopefully *will* become historic soon when FIPS > 186-3 (with support for the newer SHA variants) finally is released! >=20 >=20 > > Comments? I think we'd want something reasonably simple in the spec, > > but on the other hand, it should be technically coherent as well. > > I'm planning to sketch something before Prague, but any kinds > > of ideas (or alternative ways of looking at the problem) would > > be welcome... >=20 > My take is that it is very reasonable to describe quite many things as > "SHOULD"s only, since the ability to verify certificates depends on > PKIs and their policies anyway, and much of the responsibility can be > put there. If a CA is willing to sign certificates that are hard to > verify and if a server is willing to accept a PKI relying on such a > CA, then why not let them do this? Generally, this won't happen, > since CAs will take care to issue certificates that work well in the > intended environment. We don't have to freeze all the details of this > in the TLS specification. >=20 > Probably the TLS 1.2 specification should say more about how the > individual methods for ClientVerify work, e.g., that rsa_sign strictly > means RSASSA-PKCS1-v1_5, or possibly that RSASSA-PKCS1-v1_5 is what > SHOULD be used for rsa_sign. I think we should keep > ClientCertificateTypes in the CertificateRequest, but maybe remove the > HashType list from the CertificateRequest and instead offer a server > hello extension for this. (There's a similar client hello extension, > so this would provide more consistency within the protocol.) >=20 > Fixing the hash to SHA-1 for DSA is bad. (As an aside, indeed there > are some cases where the new TLS 1.2 draft correctly says "DSA" > instead of the incorrect "DSS" -- maybe this finally should be > corrected throughout the document; i.e., merely mention the "DSS" > terminology in a historical note.) This SHA-1-only approach won't > work well when FIPS 186-3 is released, so we should prepare something > for the new SHAs. (This affects both the ServerKeyExchange and the > CertificateVerify messages.) >=20 > Similarly, the rule that ties the hash used for RSA signing to the > hash used for the respective certificate's signature is problematic. > In both cases (ServerKeyExchange and CertificateVerify), the "Cert > Hash Types" extension could be turned into a more general "Signature > Hash Types" extension (both as a client-side extension and a > server-side extension) that also covers the signatures within TLS, not > just those appearing in certificates. The "rsa" and "dsa" cases of > the Signature type probably should be equipped with HashType fields so > that signatures can be verified without having to guess! >=20 > Bodo >=20 >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From supersweetlovely@yahoo.co.uk Sun Mar 18 19:37:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT4wK-00023l-0W for TLS-ARCHIVE@LISTS.IETF.ORG; Sun, 18 Mar 2007 19:37:28 -0400 Received: from [60.11.209.34] (helo=allabout.co.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HT4wE-00064I-0N for TLS-ARCHIVE@LISTS.IETF.ORG; Sun, 18 Mar 2007 19:37:25 -0400 Received: from ugzbjcfpav4 (unknown [10.98.7.25]) by smtp19 (Coremail) with SMTP id f4i0mGACeQEJ6lzw.1 for ; Mon, 12 Apr 2004 07:24:46 +0800 (CST) X-Originating-IP: [10.98.7.25] Subject: =?iso-2022-jp?B?GyRCPXUkMSRGJC8kQCQ1JCQbKEI=?= From: =?shift-jis?B?g32DhA==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C76339.27CE36A0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.6 (++++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C76339.27CE36A0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $BFMA3$9$_$^$;$s!#C]Cf!!bC;R$H?=$7$^$9!#7k:'$7$F#1#2G/L$$@$K;R6!$,=PMh$^$;$s!#2?$+$K$D$1$F$=$N;v$K4X$7$F8H$K$$$d$_$r8@$o$l$^$9!"$7$+$bIW$O30$K=w$,$$$k$h$&$G:G6a$O$[$H$s$IAj
=1B$BFMA3$9$_$^$;$s!#C]Cf!!bC;R$H?=3D$7$^$9!#7k:'$7$F#1#2G/L$$@$= K;R6!$,=3DPMh$^$;$s!#2?$+$K$D$1$F$=3D$N;v$K4X$7$F8H$K$$$d$_$r8@$o$l$^$9!"= $7$+$bIW$O30$K=3Dw$,$$$k$h$&$G:G6a$O$[$H$s$IAjhttp://rvze.com/?nh06
 
 
------=_NextPart_000_0009_01C76339.27CE36A0-- From tls-bounces@lists.ietf.org Mon Mar 19 13:44: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 1HTLqk-0004P5-Ds; Mon, 19 Mar 2007 13:40:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLqh-0004Je-58 for tls@ietf.org; Mon, 19 Mar 2007 13:40:47 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTLqN-0002gv-Hk for tls@ietf.org; Mon, 19 Mar 2007 13:40:47 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA28618; Mon, 19 Mar 2007 19:40:08 +0200 (MESZ) From: Martin Rex Message-Id: <200703191740.SAA07589@uw1048.wdf.sap.corp> Subject: Re: [TLS] TLS 1.2 and hash agility for signatures To: Pasi.Eronen@nokia.com Date: Mon, 19 Mar 2007 18:40:03 +0100 (MET) In-Reply-To: from "Pasi.Eronen@nokia.com" at Mar 17, 7 07:28:45 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: de4f315c9369b71d7dd5909b42224370 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 Pasi.Eronen@nokia.com wrote: > > Given that some signature algorithms have more tweakable parameters > than just the hash algorithm (e.g. PSS has salt length, MGF and the > MGF's hash algorithm), perhaps the simplest solution would be just to > use DER-encoded AlgorithmIdentifier structures (instead of defining > a new IANA-maintained number space just for TLS)? > > (Of course, a sane implementation probably wouldn't include a > DER encoder/decoder, but just list of octet strings for things it > supports; e.g. 0x3021300906052b0e03021a05000414 for RSASSA-PKCS1-v1_5 > with SHA-1.) Aren't the RSA-PSS additional parameters included in the algorithm identifier structure, which results in a non-static Octetstring? -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Mar 19 14:18: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 1HTMQR-0000uW-4w; Mon, 19 Mar 2007 14:17:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMQP-0000pV-7T for tls@ietf.org; Mon, 19 Mar 2007 14:17:41 -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 1HTMQ5-0006m9-C6 for tls@ietf.org; Mon, 19 Mar 2007 14:17:41 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2JIGpgW032401; Mon, 19 Mar 2007 20:17:15 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 20:17:09 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 20:17:09 +0200 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] TLS 1.2 and hash agility for signatures Date: Mon, 19 Mar 2007 20:17:08 +0200 Message-ID: In-Reply-To: <200703191740.SAA07589@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS 1.2 and hash agility for signatures Thread-Index: AcdqTabJ4AJG/pR+TUqyqvIhXram2QABEpGw References: from "Pasi.Eronen@nokia.com" at Mar 17, 7 07:28:45 pm <200703191740.SAA07589@uw1048.wdf.sap.corp> From: To: , X-OriginalArrivalTime: 19 Mar 2007 18:17:09.0328 (UTC) FILETIME=[CED50D00:01C76A52] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Martin Rex wrote: > > (Of course, a sane implementation probably wouldn't include a=20 > > DER encoder/decoder, but just list of octet strings for things it > > supports; e.g. 0x3021300906052b0e03021a05000414 for=20 > > RSASSA-PKCS1-v1_5 with SHA-1.) >=20 > Aren't the RSA-PSS additional parameters included in the algorithm > identifier structure, which results in a non-static Octetstring? Yes and no... the additional parameters are included in the algorithm identifier structure, but probably a PSS implementation would support only a couple of different combinations. And those could be hardcoded. (And I wouldn't expect anyone to really use PSS... but we want=20 the signature algorithm agility done right, so we don't need to revisit this topic in TLS 1.3 :-) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Mar 19 14:28: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 1HTMZm-0000dz-S9; Mon, 19 Mar 2007 14:27:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMZl-0000cI-JN for tls@ietf.org; Mon, 19 Mar 2007 14:27:21 -0400 Received: from sd-green-bigip-145.dreamhost.com ([208.97.132.145] helo=randymail-a10.g.dreamhost.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTMZR-00038Q-Hv for tls@ietf.org; Mon, 19 Mar 2007 14:27:21 -0400 Received: from delta.rtfm.com (dhcp-167a.ietf68.org [130.129.22.122]) by randymail-a10.g.dreamhost.com (Postfix) with ESMTP id 763E510F948 for ; Mon, 19 Mar 2007 11:26:56 -0700 (PDT) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 59F151CC22 for ; Mon, 19 Mar 2007 11:25:48 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Mon, 19 Mar 2007 11:25:48 -0700 From: EKR Message-Id: <20070319182548.59F151CC22@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: Subject: [TLS] Call for scribes 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 Can we please get volunteers for jabber scribes and minute takers for tomorrow's TLS meeting... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 20 08:30: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 1HTdSv-0005Fa-R1; Tue, 20 Mar 2007 08:29:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdSu-0005As-K9 for tls@ietf.org; Tue, 20 Mar 2007 08:29:24 -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 1HTdSn-0006hq-6r for tls@ietf.org; Tue, 20 Mar 2007 08:29:24 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2KCSqko019984 for ; Tue, 20 Mar 2007 14:29:15 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 14:29:05 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 14:29:05 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Mar 2007 14:29:04 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AES-GCM drafts as WG items Thread-Index: Acdq61ktf0p9IXJISJW0m9hLlA8sPQ== From: To: X-OriginalArrivalTime: 20 Mar 2007 12:29:05.0916 (UTC) FILETIME=[59C303C0:01C76AEB] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [TLS] AES-GCM drafts as WG items 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 meeting in Prague earlier today supported adopting the two=20 AES-GCM documents (draft-salowey-tls-rsa-aes-gcm and draft-rescorla-tls-suiteb) as TLS working group documents.=20 As usual, the WG consensus needs to be confirmed on the mailing list. Please mail me and Eric (or the whole list) if you object to using these documents as starting points for further WG work. (If you have a comment about some technical detail of the drafts, please use a separate thread. It's already known that the documents are not ready, and need more work.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 20 08:30: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 1HTdRX-000332-9E; Tue, 20 Mar 2007 08:27:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdRV-00032f-LG for tls@ietf.org; Tue, 20 Mar 2007 08:27:57 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTdRL-0006CQ-VY for tls@ietf.org; Tue, 20 Mar 2007 08:27:57 -0400 Received: from [80.142.183.21] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1HTdRG3TXk-0007Cc; Tue, 20 Mar 2007 13:27:43 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 8ACD81B5F3; Tue, 20 Mar 2007 13:27:37 +0100 (CET) Date: Tue, 20 Mar 2007 13:27:37 +0100 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] TLS 1.2 and hash agility for signatures Message-ID: <20070320122737.GA19513@tau.invalid> References: <20070306143001.GA19204@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX19oMF/IA82a9Wl3E79HEs3KcbLzef3ljuLtnrY UIAUglil1o4EWl0RGWrSlycviB4v4Na0uZh/sZuit/5cRQMxk1 8uPg9Nj2Jei0b2LukMKVw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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, Mar 17, 2007 at 07:28:45PM +0200, Pasi.Eronen@nokia.com wrote: > And thanks for a detailed reply! I had overlooked the fact that TLS > indeed does not require the *client* certificate's algorithm to match > the cipher suite. > > Regarding the Signature structure (in ServerKeyExchange and > CertificateVerify), I agree that we probably need to include a field > that tells which hash algorithm was used. In RSASSA-PKCS1-v1_5, the > signature itself includes the algorithm identifier, but this is not > the case for DSA (or ECDSA, for what matter)... so if the certificate > does not specify a single unique allowed algorithm, we need to tell > which was used in TLS. The Signature structure not only does not specify the hash, it does not even specify anything about the SignatureAlgorithm. The server-side SignatureAlgorithm, of course, is determined by the ciphersuite, which always is known by both parties. The client-side SignatureAlgorithm, however, is only determined by the ClientCertificateType, which is never explicitly transmitted: there's just a list of type values sent by the server in the CertificateRequest, so the client's choice of one of these is meant to be implied by what it sends in the Certificate message, and additionally in certain cases by whether or not the it sends a CertificateVerify message. I guess it's best to include a ClientCertificateType field into the client's Certificate message (not the CertificateVerify message since some methods don't use it): struct { select (sender_of_this_message) { case client: ClientCertificateType certificate_type; case server: }; ASN.1Cert certificate_list<0..2^24-1>; } Certificate; (Here I'm using a "select" construction and not a separate ClientCertificate type since it makes some sense to keep the current handshake type for this message, and since there's currently a correspondence between handshake types and structure names. I.e., using ClientCertificate would either introduce a new inconsistency in the presentation of the protocol, or require an otherwise unnecessary new handshake type client_certificate.) You are right that including an algorithm identifier field into the Signature type make sense. I'd prefer to keep this optional since it's not always needed, since for example the "rsa" case of Signature really means RSA PKCS#1 v1.5, which does not need the algorithm identifier. Any other use of RSA signatures, such as PSS, would require new ciphersuites and new "ClientCertificateType" values (sort of a misnomer, since distinct client authentication methods don't necessarily imply distinct X.509 certificates ...), or possibly other (extension-based) ways of negotiating the use of PSS or whatever. If such ciphersuites, "ClientCertificateType" values, or extensions are ever defined, that would be the appropriate time to define an appropriate new case for the Signature structure. It seems that DSA and ECDSA indeed will be cases where we'll often need to use such an AlgorithmIdentifier (identifying the signature type, not just the hash). I think this is very unfortunate since really the *certificate* containing an DSA or ECC key should restrict the key to be used with a single specific signing algorithm (and, thus, only a single hash function), but since it doesn't look like we can rely on PKIX imposing such restrictions, we have to adapt to such flexibility. > Given that some signature algorithms have more tweakable parameters > than just the hash algorithm (e.g. PSS has salt length, MGF and the > MGF's hash algorithm), perhaps the simplest solution would be just to > use DER-encoded AlgorithmIdentifier structures (instead of defining > a new IANA-maintained number space just for TLS)? > > (Of course, a sane implementation probably wouldn't include a > DER encoder/decoder, but just list of octet strings for things it > supports; e.g. 0x3021300906052b0e03021a05000414 for RSASSA-PKCS1-v1_5 > with SHA-1.) > > If we use the AlgorithmIdentifier structure in the Signature, > would that also work for the cert_hash_types extension? (Which, > as you point, could be really called "signature_hash_types" > since it also covers signatures outside certs.) You mean, to indicate hash algorithms in this case (not signature algorithms)? I'd prefer using a brief list of identifiers defined in the TLS specification (which is exactly what HashType is now), to be interpreted as a hint and not as a complete description of what the party in question can handle. (In some cases, depending on the software design, we might have implementations that can handle certain hash functions for some signature algorithms but not for others. We can't put all such details into a HashType list. Possibly we could cope with this by using a list of *signature* AlgorithmIdentifiers, but such a list easily could become very huge, and still wouldn't solve all problems related to signature and certificate verification. This would be a lot of effort spent on an incomplete solution for a problem that doesn't really matter that much. In practice, if signature verification works, this is usually to a large part because we have CA procedures that ensure that certificates can be handled by many clients. And if signature verification doesn't work, then even if we can detect this problem in advance through complex negotiation of capabilities, this often won't buy us much since there's no alternative certificate available. We may still be able to continue the handshake, though, if signature verification is not considered crucial for the present session.) If we change the current "Cert Hash Types" extension into a "Signature Hash Types" extension to be used both by clients and servers, in addition to including a ClientCertificateType field into the client's Certificate message and including an optional algorithm identifier into the Signature type, then I think this would achieve a reasonable balance between keeping the protocol simple and keeping it flexible. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 20 08:56:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTds5-0008Rl-HL; Tue, 20 Mar 2007 08:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTds4-0008Rg-TN for tls@ietf.org; Tue, 20 Mar 2007 08:55:24 -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 1HTds2-0004E6-8O for tls@ietf.org; Tue, 20 Mar 2007 08:55:24 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2KCt7ZH012764; Tue, 20 Mar 2007 14:55:16 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 14:55:13 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 14:55:13 +0200 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] TLS 1.2 and hash agility for signatures Date: Tue, 20 Mar 2007 14:55:11 +0200 Message-ID: In-Reply-To: <20070320122737.GA19513@tau.invalid> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS 1.2 and hash agility for signatures Thread-Index: Acdq6ysITzJdrFayTZecO/JvZ8+isgAAOblQ References: <20070306143001.GA19204@tau.invalid> <20070320122737.GA19513@tau.invalid> From: To: X-OriginalArrivalTime: 20 Mar 2007 12:55:13.0235 (UTC) FILETIME=[FFF4EA30:01C76AEE] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070320145516-2FA7FBB0-651C6158/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Bodo Moeller wrote: > I guess it's best to include a ClientCertificateType field into the > client's Certificate message (not the CertificateVerify message since > some methods don't use it): Hmmm... why do we need ClientCertificateType in the Certificate=20 message, if we also add the algorithm identifier to Signature type=20 (also for RSA)? > You are right that including an algorithm identifier field into the > Signature type make sense. I'd prefer to keep this optional since > it's not always needed, since for example the "rsa" case of Signature > really means RSA PKCS#1 v1.5, which does not need the algorithm > identifier. =20 In today's meeting somebody pointed out that we probably want the identifier for RSA PKCS# v1.5 as well, since some crypto libraries export an API that matches the "signature verification operation" described in RFC 3447 Section 8.2.2. And there you actually need to know which hash algorithm was used before you start verifying the signature... > Any other use of RSA signatures, such as PSS, would require new=20 > ciphersuites and new "ClientCertificateType" values (sort > of a misnomer, since distinct client authentication methods don't > necessarily imply distinct X.509 certificates ...), or possibly other > (extension-based) ways of negotiating the use of PSS or whatever. =20 I agree, PSS server certificates would be best handled by new cipher suites, and PSS client certificates with new client certificate types. > > If we use the AlgorithmIdentifier structure in the Signature, > > would that also work for the cert_hash_types extension? (Which, > > as you point, could be really called "signature_hash_types"=20 > > since it also covers signatures outside certs.) >=20 > You mean, to indicate hash algorithms in this case (not signature > algorithms)? I'd prefer using a brief list of identifiers defined in > the TLS specification (which is exactly what HashType is now), to be > interpreted as a hint and not as a complete description of what the > party in question can handle. > > (In some cases, depending on the software design, we might have > implementations that can handle certain hash functions for some > signature algorithms but not for others. We can't put all such > details into a HashType list. Possibly we could cope with this by > using a list of *signature* AlgorithmIdentifiers, but such a list > easily could become very huge, and still wouldn't solve all problems > related to signature and certificate verification. =20 I was thinking about signature algorithm identifiers; but I do agree that the list could easily get quite long.=20 Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 20 09:14: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 1HTe9S-0001Ms-KI; Tue, 20 Mar 2007 09:13:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTe9R-0001M7-Sr for tls@ietf.org; Tue, 20 Mar 2007 09:13:21 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTe9D-000252-G0 for tls@ietf.org; Tue, 20 Mar 2007 09:13:21 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2KDCnTu022885; Tue, 20 Mar 2007 15:13:05 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 15:13:05 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 15:13:05 +0200 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] Review of draft-santesson-tls-gssapi-00 Date: Tue, 20 Mar 2007 15:13:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdiY7lJoKRQ2U67QoOjcWIzSPZdQgCWjgAwAYxw6jA= References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com> From: To: X-OriginalArrivalTime: 20 Mar 2007 13:13:05.0160 (UTC) FILETIME=[7EDFB080:01C76AF1] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070320151305-594D0BB0-4E5230F9/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Stefan Santesson wrote: > > As for taking security out of the picture, that was your claim not > > mine. For me, this state machine issue *is* a security issue and > > it's not purely an issue of establishing a key with a sufficiently > > strong algorithm. >=20 > What other security issue than the strength of the key is there? > TLS does not require any user authentication, so any added=20 > technology here can only be positive if the alternative in anonymous. >=20 > Regarding key strength, I think all cryptographic experts=20 > would agree that: >=20 > Good key XOR bad key =3D good key >=20 > At least if they are produced independent of each other, e.g. that > the bad key is not actively selected with knowledge of the good key > to cancel it or make it bad. Following this logic, you can safely > have another process creating a key of un-known strength and XOR it > with the "good" key of TLS, and preserve the security level of TLS. >=20 > This simple assumption, makes the security impact very easy=20 > to analyze with respect to cryptographic strength. I'm not sure what Eric had in mind here, but I don't think key strength is the issue here. As we found out with e.g. PEAP and IKEv2, adding a new layer or round of authentication can *reduce* security=20 if the layers/rounds are not coupled together in the right way. This *is* a big deal! (I'm referring to the "Man-in-the-Middle in Tunneled Authentication" paper by Asokan, Niemi and Nyberg; and related work.) I think Eric's concern was that the proposal would be easier to analyze if the interaction between current TLS state machine and GSS-API would be done in some other way that in the current draft. > If it would not turn out to be a big deal, we have a significant win > here by allowing numerous non-PKI based authentication technologies > to be used with TLS. That is a "big deal". No disagreement from me here... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 20 09:15: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 1HTeAV-0001bz-5h; Tue, 20 Mar 2007 09:14:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeAU-0001bq-Be for tls@ietf.org; Tue, 20 Mar 2007 09:14:26 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTeA4-0002JA-8m for tls@ietf.org; Tue, 20 Mar 2007 09:14:26 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2KDDamP011403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Mar 2007 14:13:36 +0100 From: Simon Josefsson To: References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070320:tls@ietf.org::zXx4roQ6sGQNDFYS:4mzG X-Hashcash: 1:22:070320:pasi.eronen@nokia.com::WB4YnlBXs9v/7FUE:I288 Date: Tue, 20 Mar 2007 14:13:34 +0100 In-Reply-To: (Pasi Eronen's message of "Tue\, 20 Mar 2007 14\:29\:04 +0200") Message-ID: <87hcsgukg1.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.8 required=4.0 tests=AWL,BAYES_40, 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.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tls@ietf.org Subject: [TLS] Re: AES-GCM drafts as WG items 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 writes: > The meeting in Prague earlier today supported adopting the two > AES-GCM documents (draft-salowey-tls-rsa-aes-gcm and > draft-rescorla-tls-suiteb) as TLS working group documents. > > As usual, the WG consensus needs to be confirmed on the mailing list. > Please mail me and Eric (or the whole list) if you object to > using these documents as starting points for further WG work. Have the authors filed the required IPR disclosures? If I can't implement these documents due to patents, I'd object to adopting them intended for standards-track status. There is a IPR disclose related to ECC at: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=750 The information in the PDF suggests to me that not everything can be implemented freely. It further says that the disclosure doesn't cover other IETF documents, which presumably would include draft-rescorla-tls-suiteb. I'm not familiar with the IPR status of AES-GCM. Anyone else who knows more? Btw, SHA-2 is patented by NSA, but they have not yet filed the required disclosure to the IETF. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 20 09:28:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeMz-00075Q-Pg; Tue, 20 Mar 2007 09:27:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeMx-00075I-U5 for tls@ietf.org; Tue, 20 Mar 2007 09:27:19 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTeMr-0007Ik-RY for tls@ietf.org; Tue, 20 Mar 2007 09:27:19 -0400 Received: from [80.142.183.21] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1HTeMm1qA2-0006UL; Tue, 20 Mar 2007 14:27:08 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 7FCCA1B5F3; Tue, 20 Mar 2007 14:27:07 +0100 (CET) Date: Tue, 20 Mar 2007 14:27:07 +0100 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] TLS 1.2 and hash agility for signatures Message-ID: <20070320132707.GB21988@tau.invalid> References: <20070306143001.GA19204@tau.invalid> <20070320122737.GA19513@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1+Io/hmUcJ8laKZMoSfqyr/kyT2Eqr3LY0FCAN PdQDWXfSNi/O+hVs1JBpk0KBlNjTmiVFYLCHOkH5Vx1LPVAo3P wvAlEHqz5UbvPilLdT8cw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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, Mar 20, 2007 at 02:55:11PM +0200, Pasi.Eronen@nokia.com wrote: > Bodo Moeller wrote: >> I guess it's best to include a ClientCertificateType field into the >> client's Certificate message (not the CertificateVerify message since >> some methods don't use it): > > Hmmm... why do we need ClientCertificateType in the Certificate > message, if we also add the algorithm identifier to Signature type > (also for RSA)? For the fixed-DH and fixed-ECDH client verification methods, there's no CertificateVerify message and thus no Signature structure. The signature algorithm identifier applies only to client verification methods that do use signatures. Currently, fixed-DH and fixed-ECDH are the only exceptions, and these can easily be detected by just looking at what messages the client sends (just a Certifcicate -- empty ClientKeyExchange, no CertificateVerify). This has a somewhat kludgy feel, though, and new client verification methods may not have such distinctive patterns. >> You are right that including an algorithm identifier field into the >> Signature type make sense. I'd prefer to keep this optional since >> it's not always needed, since for example the "rsa" case of Signature >> really means RSA PKCS#1 v1.5, which does not need the algorithm >> identifier. > In today's meeting somebody pointed out that we probably want the > identifier for RSA PKCS# v1.5 as well, since some crypto libraries > export an API that matches the "signature verification operation" > described in RFC 3447 Section 8.2.2. And there you actually need to > know which hash algorithm was used before you start verifying the > signature... Well, I guess this makes sense. Maybe *looking* at the algorithm identifier should be made optional then. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 20 09:54: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 1HTelg-0000VD-Me; Tue, 20 Mar 2007 09:52:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTelf-0000V4-Q4 for tls@ietf.org; Tue, 20 Mar 2007 09:52:51 -0400 Received: from sd-green-bigip-74.dreamhost.com ([208.97.132.74] helo=randymail-a8.g.dreamhost.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTeld-0004Iq-Ds for tls@ietf.org; Tue, 20 Mar 2007 09:52:51 -0400 Received: from delta.rtfm.com (dhcp-167a.ietf68.org [130.129.22.122]) by randymail-a8.g.dreamhost.com (Postfix) with ESMTP id B8DA5AF546; Tue, 20 Mar 2007 06:52:48 -0700 (PDT) Received: by delta.rtfm.com (Postfix, from userid 1001) id 04B181CC24; Tue, 20 Mar 2007 06:51:40 -0700 (PDT) To: Simon Josefsson Subject: Re: [TLS] Re: AES-GCM drafts as WG items References: <87hcsgukg1.fsf@mocca.josefsson.org> From: EKR Date: Tue, 20 Mar 2007 06:51:40 -0700 In-Reply-To: <87hcsgukg1.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 20 Mar 2007 14:13:34 +0100") Message-ID: <861wjk10r7.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Reply-To: EKR 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 writes: > writes: > >> The meeting in Prague earlier today supported adopting the two >> AES-GCM documents (draft-salowey-tls-rsa-aes-gcm and >> draft-rescorla-tls-suiteb) as TLS working group documents. >> >> As usual, the WG consensus needs to be confirmed on the mailing list. >> Please mail me and Eric (or the whole list) if you object to >> using these documents as starting points for further WG work. > > Have the authors filed the required IPR disclosures? I was thinking that the ECC disclosures covered this, since it's the same algorithms as in the existing ECC RFC (RFC 4492) Sounds like it doesn't, so I'll need to file something... It's now on my list. > If I can't implement these documents due to patents, I'd object to > adopting them intended for standards-track status. The plan would be the same Info status as RFC 4492. > There is a IPR disclose related to ECC at: > > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=750 > > The information in the PDF suggests to me that not everything can be > implemented freely. It further says that the disclosure doesn't cover > other IETF documents, which presumably would include > draft-rescorla-tls-suiteb. Thanks for the heads-up on this. > I'm not familiar with the IPR status of AES-GCM. Anyone else who > knows more? Not sure, but other GCM drafts have no IPR disclosures. > Btw, SHA-2 is patented by NSA, but they have not yet filed the > required disclosure to the IETF. I was not aware of this. The usual procedure is for someone to file a 3rd party disclosure and then the secretariat will contact the patent holder... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 20 10:14: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 1HTf5S-0002qP-OH; Tue, 20 Mar 2007 10:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTf5Q-0002qE-Uz for tls@ietf.org; Tue, 20 Mar 2007 10:13:16 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTf5L-0001EJ-V2 for tls@ietf.org; Tue, 20 Mar 2007 10:13:16 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2KECw8r023095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Mar 2007 15:12:59 +0100 From: Simon Josefsson To: EKR References: <87hcsgukg1.fsf@mocca.josefsson.org> <861wjk10r7.fsf@delta.rtfm.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070320:tls@ietf.org::fJQA/D+xW5bHluJs:1TSW X-Hashcash: 1:22:070320:ekr@networkresonance.com::XlpwrCWtMxhsg9YD:2rSj Date: Tue, 20 Mar 2007 15:12:58 +0100 In-Reply-To: <861wjk10r7.fsf@delta.rtfm.com> (ekr@networkresonance.com's message of "Tue\, 20 Mar 2007 06\:51\:40 -0700") Message-ID: <871wjkuhp1.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.0 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.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tls@ietf.org Subject: [TLS] Re: AES-GCM drafts as WG items 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 EKR writes: > Simon Josefsson writes: > >> writes: >> >>> The meeting in Prague earlier today supported adopting the two >>> AES-GCM documents (draft-salowey-tls-rsa-aes-gcm and >>> draft-rescorla-tls-suiteb) as TLS working group documents. >>> >>> As usual, the WG consensus needs to be confirmed on the mailing list. >>> Please mail me and Eric (or the whole list) if you object to >>> using these documents as starting points for further WG work. >> >> Have the authors filed the required IPR disclosures? > > I was thinking that the ECC disclosures covered this, since it's the > same algorithms as in the existing ECC RFC (RFC 4492) Sounds like it > doesn't, so I'll need to file something... It's now on my list. Thanks! >> If I can't implement these documents due to patents, I'd object to >> adopting them intended for standards-track status. > > The plan would be the same Info status as RFC 4492. Great. Then I have no objection to adopting the document. I note that draft-salowey-tls-rsa-aes-gcm-00 says: Intended status: Standards Track >> Btw, SHA-2 is patented by NSA, but they have not yet filed the >> required disclosure to the IETF. > > I was not aware of this. The usual procedure is for someone to file > a 3rd party disclosure and then the secretariat will contact > the patent holder... I filed this some time ago, but I've no idea if the secretariat have done anything with it. https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=795 /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 20 10:39: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 1HTfUA-0007Eb-0z; Tue, 20 Mar 2007 10:38:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfU7-0007E5-Vw for tls@ietf.org; Tue, 20 Mar 2007 10:38:47 -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 1HTfTw-0005ci-77 for tls@ietf.org; Tue, 20 Mar 2007 10:38:47 -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 l2KEcRFj018898; Tue, 20 Mar 2007 16:38:34 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 16:38:10 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 16:38:10 +0200 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] Re: AES-GCM drafts as WG items Date: Tue, 20 Mar 2007 16:38:10 +0200 Message-ID: In-Reply-To: <871wjkuhp1.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: AES-GCM drafts as WG items Thread-Index: Acdq+l/OznGrUlAvTQKtwJg/pQ5jGwAAp67A References: <87hcsgukg1.fsf@mocca.josefsson.org> <861wjk10r7.fsf@delta.rtfm.com> <871wjkuhp1.fsf@mocca.josefsson.org> From: To: X-OriginalArrivalTime: 20 Mar 2007 14:38:10.0640 (UTC) FILETIME=[61FA1D00:01C76AFD] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070320163834-49C59BB0-6AA4825A/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Simon Josefsson wrote: > I filed this some time ago, but I've no idea if the secretariat have > done anything with it. >=20 > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D795 I talked with our new AD about this, and he promised to get in touch with the right persons inside NIST and NSA to make sure this is handled according to the IETF rules. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 20 11:06: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 1HTftR-0008Ud-Bv; Tue, 20 Mar 2007 11:04:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTftQ-0008UY-R6 for tls@ietf.org; Tue, 20 Mar 2007 11:04:56 -0400 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTftG-0001xr-5w for tls@ietf.org; Tue, 20 Mar 2007 11:04:56 -0400 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 20 Mar 2007 15:04:45 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Tue, 20 Mar 2007 15:04:20 +0000 From: Stefan Santesson To: "Pasi.Eronen@nokia.com" Date: Tue, 20 Mar 2007 15:04:18 +0000 Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdiY7lJoKRQ2U67QoOjcWIzSPZdQgCWjgAwAYxw6jAAA645UA== Message-ID: References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) 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 The problem is that it is very hard to engage into a discussion unless the = objections are substantiated. Considering the original proposal there is 1 isolated event (the GSS exchan= ge) that hands a very specific piece of information to a standard TLS initi= alization process. This happens to be input to key derivation. 5. Key Derivation After successful completion of the gss_token messages, the client and server each obtain 46 bytes of key random data using the GSS-API PRF. This data is the TLS pre-master secret. Therefore it is hard to understand what other security concerns there could= be in the context of TLS other than the quality of the resulting key. Structurally, the problem with your proposal that has been pointed out to m= e is that many use of TLS requires authentication have to be established be= fore the finished message, or it will be useless. This aspect needs to be a= nalyzed to determined whether completing authentication before the finished= message is an absolute requirement for a solution to be meaningful. As I understand this, the current status of this work is that we have not y= et decided to adopt this work item, but that we should explore this issue f= urther to see if we can come up with an acceptable solution. It would be gr= eat if you could confirm and elaborate how we will work towards a decision = to accept or reject this work. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: den 20 mars 2007 14:13 > To: Stefan Santesson > Cc: tls@ietf.org > Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00 > > Stefan Santesson wrote: > > > > As for taking security out of the picture, that was your claim not > > > mine. For me, this state machine issue *is* a security issue and > > > it's not purely an issue of establishing a key with a sufficiently > > > strong algorithm. > > > > What other security issue than the strength of the key is there? > > TLS does not require any user authentication, so any added > > technology here can only be positive if the alternative in anonymous. > > > > Regarding key strength, I think all cryptographic experts > > would agree that: > > > > Good key XOR bad key =3D good key > > > > At least if they are produced independent of each other, e.g. that > > the bad key is not actively selected with knowledge of the good key > > to cancel it or make it bad. Following this logic, you can safely > > have another process creating a key of un-known strength and XOR it > > with the "good" key of TLS, and preserve the security level of TLS. > > > > This simple assumption, makes the security impact very easy > > to analyze with respect to cryptographic strength. > > I'm not sure what Eric had in mind here, but I don't think key > strength is the issue here. As we found out with e.g. PEAP and IKEv2, > adding a new layer or round of authentication can *reduce* security > if the layers/rounds are not coupled together in the right way. > This *is* a big deal! > > (I'm referring to the "Man-in-the-Middle in Tunneled Authentication" > paper by Asokan, Niemi and Nyberg; and related work.) > > I think Eric's concern was that the proposal would be easier to > analyze if the interaction between current TLS state machine and > GSS-API would be done in some other way that in the current draft. > > > > If it would not turn out to be a big deal, we have a significant win > > here by allowing numerous non-PKI based authentication technologies > > to be used with TLS. That is a "big deal". > > No disagreement from me here... > > Best regards, > Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Mar 20 13:02: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 1HThhZ-00076I-9o; Tue, 20 Mar 2007 13:00:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThhX-00075r-NB for tls@ietf.org; Tue, 20 Mar 2007 13:00:47 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HThhD-0007OS-0I for tls@ietf.org; Tue, 20 Mar 2007 13:00:47 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2KH00xm008778; Tue, 20 Mar 2007 19:00:24 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 19:00:22 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 19:00:22 +0200 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] Review of draft-santesson-tls-gssapi-00 Date: Tue, 20 Mar 2007 19:00:22 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdiY7lJoKRQ2U67QoOjcWIzSPZdQgCWjgAwAYxw6jAAA645UAACBL/g References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com> From: To: X-OriginalArrivalTime: 20 Mar 2007 17:00:22.0422 (UTC) FILETIME=[3F50BB60:01C76B11] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 Stefan Santesson wrote: > The problem is that it is very hard to engage into a discussion=20 > unless the objections are substantiated. I can repeat one specific objection (made by several people already): *all* current TLS key exchange mechanisms use exactly the same state machine, i.e. the message exchange shown in Fig. 1 of RFC 2246, while this proposal doesn't. This would be quite radical change to TLS. For example, the base=20 TLS spec assumes this state machine is always used, so either we=20 need to change it to accommodate GSS-API, or the GSS-API document=20 has to effectively overrule the base spec in many places. (I also believe that implementation could be easier if the state machine is not changed, but that's probably a secondary concern.) > Structurally, the problem with your proposal that has been pointed > out to me is that many use of TLS requires authentication have to be > established before the finished message, or it will be useless. This > aspect needs to be analyzed to determined whether completing > authentication before the finished message is an absolute > requirement for a solution to be meaningful. Could you explain why you think it will be useless? We certainly have to complete the authentication (including GSS-API) before we let application data through. In my proposal, that would happen after the channel binding messages (not immediately after the finished messages). > As I understand this, the current status of this work is that=20 > we have not yet decided to adopt this work item, but that we=20 > should explore this issue further to see if we can come up=20 > with an acceptable solution. It would be great if you could=20 > confirm and elaborate how we will work towards a decision to=20 > accept or reject this work. Working backwards in time: To accept this as WG work item, we need to recharter (and the charter needs to be approved by IESG). Before I and Eric start discussions about the new charter text with our AD, we would like to have rough WG consensus that this is a good idea (and we have enough people to actively work on this, review it, etc.).=20 To determine the WG consensus, we will at some point do a straw poll, at least on the mailing list and possibly at TLS WG meeting as well. This didn't happen here in Prague, since there was no presentation about GSS-API. On one hand, I would prefer to do a poll in a meeting (I find it usually works better); on the other hand, I would also prefer to have this settled before Chicago.=20 Various people (not only Eric :-) have expressed objections to the=20 current version of the draft, and some people have proposed changes=20 that would make it more acceptable to them. Before the straw poll,=20 I think you should use the opportunity to have more discussion on=20 the list, and revise the document (in whatever way you think would=20 make the document more acceptable to the WG and help its progress). (One related comment: the current draft has lot of technical details, but practically no text about *why* you would want to do this. The motivation has been explained in various presentations and discussions, but I think including it in the document itself would be helpful.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 00:11: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 1HTs7g-0000Jq-VP; Wed, 21 Mar 2007 00:08:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTs7f-0000Jg-Ml for tls@lists.ietf.org; Wed, 21 Mar 2007 00:08:27 -0400 Received: from smtp110.plus.mail.mud.yahoo.com ([68.142.206.243]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTs7b-0008J6-CK for tls@lists.ietf.org; Wed, 21 Mar 2007 00:08:27 -0400 Received: (qmail 21397 invoked from network); 21 Mar 2007 04:08:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-Version:Content-Transfer-Encoding:Message-Id:Content-Type:To:From:Subject:Date:X-Mailer; b=IrtIklmMa5DkdbeaM0jfV5Ygt0IFYTuRdV9UiGMsaGerEpCvgcEEpKpRJF5u21wdj5qk8vsH6PEUKEa+UreMrFhW01TpfGPm5Zng3IKtJfFVEweXEQoZLLHd5gumoBP47ms7npe3G46I1VcODSExwnxdw3+OVDvQkZpSz52Ppk8= ; Received: from unknown (HELO ?192.168.1.2?) (reefedjib@24.18.133.25 with plain) by smtp110.plus.mail.mud.yahoo.com with SMTP; 21 Mar 2007 04:08:22 -0000 X-YMail-OSG: E9cGxo0VM1mHaAv2gXUmpq6zevkNzXvHTO1XHAfSdhkHWNcmFZGvME1oC3hgFopXyxCFjSfZXUmEB0y3DtfZ4juZPYuUdV.2ze73OuyTzyWQOMxtqWdHzPD_XIZVWF5VIIc8wS_9klv4tII- Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <3B8BD74C-1897-43E4-8259-061AEC42C92B@yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: TLS-list From: Robert Withers Date: Tue, 20 Mar 2007 21:08:19 -0700 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [TLS] Help with DER decoding of a CertificateExtension value 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 realize this is the wrong forum for this, but I hope someone may be able to help clarify this. I was unable to find a working list for asn1. I have a chunk of DER encoded bytes, which is the value of a CertificateExtension, that I am trying to decode. I am getting something funny. Here is the raw data: 30328210686F6D652E73656C666973682E6F7267A01E06082B06010505070805A0120C10 686F6D652E73656C666973682E6F7267 I analyzed the structure when decoding and I get the following: SEQUENCE = T(30) L(32) V( Implicit [2] = T(82) L(10) V(68 6F 6D 65 2E 73 65 6C 66 69 73 68 2E 6F 72 67) Explicit [0] = T(A0) L(1E) V( OID = T(06) L(08) V(2B 06 01 05 05 07 08 05) Explicit [0] = T(A0) L(12) V( String = T(0C) L(10) V(68 6F 6D 65 2E 73 65 6C 66 69 73 68 2E 6F 72 67)))) The outer is a SEQUENCE and is ok. Inside, at the value of the first Explicit [0] Triplet, it is not a SEQUENCE, but it has 2 Triplets inside of it. Looking at its Length (1E), it thinks it should be holding both Triplets. Isn't that funny? My code is only grabbing the first Triplet when decoding an Explicit [0], and then my outer Sequence is decoding the second inner Triplet, so I actually get: Sequence ( Implicit [2] Explicit [0] (OID) Explicit [0] (String)) instead of: Sequence ( Implicit [2] Explicit [0] ( OID Explicit [0])) The corresponding length of the first Explicit [0] is messed up when I re-encode it. Plus there shouldn't be the same tag value ([0]) in the same scope, so they definitely seem nested. Could someone help me make sense of this? thanks, Robert _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 01:47: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 1HTteP-0005dU-Bo; Wed, 21 Mar 2007 01:46:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTteO-0005dK-7y for tls@ietf.org; Wed, 21 Mar 2007 01:46:20 -0400 Received: from ms-smtp-04.rdc-nyc.rr.com ([24.29.109.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTteM-00083R-Rz for tls@ietf.org; Wed, 21 Mar 2007 01:46:20 -0400 Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-04.rdc-nyc.rr.com (8.13.4/8.13.4) with ESMTP id l2L5kHFE008811 for ; Wed, 21 Mar 2007 01:46:17 -0400 (EDT) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.6) with ESMTP id md50000047415.msg for ; Wed, 21 Mar 2007 01:47:03 -0400 Message-ID: <4600C6D4.20404@secure-endpoints.com> Date: Wed, 21 Mar 2007 01:47:00 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: stefans@microsoft.com Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 References: <20070122202751.CCBC45C01E@laser.networkresonance.com> <86mz2nr65m.fsf@raman.networkresonance.com> <86odn2e8y3.fsf@delta.rtfm.com> In-Reply-To: X-Enigmail-Version: 0.94.3.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Wed, 21 Mar 2007 01:47:03 -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.1 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 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="===============1050668946==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1050668946== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060708030400010006080809" This is a cryptographically signed message in MIME format. --------------ms060708030400010006080809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The intent of the original proposal was to replace RFC 2712 with a revised mechanism that would be extensible and permit Kerberos to be used for mutual authentication bound with an appropriate binding to the TLS session. One significant reason for selecting the use of the GSS-API Kerberos mechanism in place of raw Kerberos is for ease of implementation on operating systems that do not export raw Kerberos. (Solaris, Microsoft Windows, among others.) The model that I had in mind was SSH gssapi-keyex where the GSS-API is used to perform mutual authentication and generate key data that can be used by the encapsulating protocol which in this case would be TLS. The GSS-API PRF provides a method of generating key data that is independent of the negotiated Kerberos session keys. I am very mindful of the concerns raised by EKR. Pasi's proposal looks very much like what was developed for Telnet START-TLS and AUTH KRB5 binding many years ago except that instead of establishing an TLS session with an ADH cipher and then binding the TLS finished messages to a mutual Kerberos 5 authentication at the application layer, the new ContentType exchange would be performed prior to the completion of the TLS session establishment. I believe this approach is workable but I would like to hear how EKR would propose performing the GSS-API exchange first within the context of the TLS session establishment. It is important that the solution be entirely encompassed within the TLS session establishment in order for the result to be a transparent replacement for the existing deployed utilization of RFC 2712. The goal of the original proposal was to start TLS, negotiate GSS, and then bind the result of the GSS exchange to TLS for the completion of the TLS state machine. If EKR has a method of accomplishing this which he would accept, then I would be most eager to consider it. Thanks. Jeffrey Altman Stefan Santesson wrote: > Pasi, > > Thanks for this interesting proposal. > Let me clarify that I'm personally in no way locked on the current proposal in term of selected architecture. > As long as we can achieve the same goal. > > Your proposal is interesting as an alternative that we definitely should consider. > > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > >> -----Original Message----- >> From: EKR [mailto:ekr@networkresonance.com] >> Sent: den 9 mars 2007 16:25 >> To: Pasi.Eronen@nokia.com >> Cc: tls@ietf.org >> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 >> >> writes: >> >>> Eric Rescorla wrote: >>> >>>>>> 2) The extended roundtrips is an un-escapable consequence. If >>>>>> necessary I believe we can define an upper boundary of the number >>>>>> of roundtrips. >>>> Well, any number >2 is a radical change in the TLS state machine. >>> I agree; however, there are several ways to do the roundtrips, >>> and some of them might be slightly less radical than the one >>> current proposed in draft-santesson-tls-gssapi-01. >>> >>> Here's one sketch of how this could work: >>> >>> ClientHello >>> (ciphersuite TLS_RSA_GSSAPI_WITH_AES128_CBC_SHA, >>> gss_api extension with OID list) >>> --------> >>> ServerHello >>> (gss_api extension with OID list) >>> Certificate >>> <-------- ServerHelloDone >>> ClientKeyExchange >>> (just like in normal RSA ciphersuites) >>> ChangeCipherSpec >>> Finished --------> >>> ChangeCipherSpec >>> <-------- Finished >>> >>> Then we'd have the GSSAPI exchange: >>> >>> ContentType=GSSAPI >>> ("token", gss token data) --------> >>> >>> ContentType=GSSAPI >>> <--- ("token", gss token data) >>> >>> (........ repeat 0..N times ..........) >>> >>> ContentType=GSSAPI >>> ("complete", >>> gss_wrap(channel binding info)) -----> >>> ContentType=GSSAPI >>> ("complete", >>> gss_wrap(channel binding info)) >>> >>> Application Data <-------> Application Data >>> >>> Here "channel binding info" would be something similar as in >>> draft-williams-on-channel-binding-01. Using a different content type >>> and channel binding would avoid the need to feed stuff from GSS-API >>> to TLS record layer/handshake layer/key calculations (which AFAIK >>> was one thing Eric objected to in IETF67). >>> >>> (In addition to TLS_RSA_GSSAPI_WITH_*, we could also have >>> TLS_DHE_GSSAPI_WITH_* ciphersuites, if we need to support >>> servers without a certificate.) >>> >>> Comments? >> So, basically, you're suggesting TLS would provide a content type >> for an out-of-band channel that other protocols could use for their >> negotiation without it winding up in the app layer? This certainly >> seems better than the current proposal. >> >> An alternative proposal that seems even cleaner is to simply >> do the GSS first and then couple it to TLS with PSK. >> >> -Ekr >> >> >> _______________________________________________ >> 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 --------------ms060708030400010006080809 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 AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAzMjEwNTQ3MDBaMCMGCSqGSIb3DQEJBDEWBBQYuaN5 fchMfeKy0QLzDrJw05Q7yDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAVGwEHbj3a8bDBSWXwGtL6Wazh9mF2ZUlXjWyLPSu/f6P8A1K9SFi ZZiKjIKqG5pcUJP+ub6MlGO+6xux9aD48NEkmC40q4Cdpk/+N1dw3X/QbwodcR/tN+kuk0sY vuJp12SMTbpM7gn2AOflCdJznxuFe0XTxAziDAjQThSEh+XhoJR3nT4hu9JeytOvxM8Te9sz HSawATIMftgM7/qjwer/EDW4fvO9ihElOjlPxPKbDgicj+pMf1J9rsIZMT4nwHC8XoC2C0iB w1V5j+e0nFw+OkrLi5YqUbDpyAdIK60rHf0PNyVKLyqTS8X9ABrJaCfuKUU2wCAkqvIfBJyG GwAAAAAAAA== --------------ms060708030400010006080809-- --===============1050668946== 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 --===============1050668946==-- From tls-bounces@lists.ietf.org Wed Mar 21 05:24: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 1HTx1e-0006et-No; Wed, 21 Mar 2007 05:22:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTx1d-0006eg-67 for tls@ietf.org; Wed, 21 Mar 2007 05:22:33 -0400 Received: from [194.29.32.68] (helo=michael.checkpoint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTx1K-0001aw-Q1 for tls@ietf.org; Wed, 21 Mar 2007 05:22:33 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l2L9M4Ao017201; Wed, 21 Mar 2007 11:22:04 +0200 (IST) In-Reply-To: References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 Date: Wed, 21 Mar 2007 11:22:03 +0200 To: "" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Mar 20, 2007, at 7:00 PM, wrote: > Stefan Santesson wrote: > >> The problem is that it is very hard to engage into a discussion >> unless the objections are substantiated. > > I can repeat one specific objection (made by several people already): > *all* current TLS key exchange mechanisms use exactly the same state > machine, i.e. the message exchange shown in Fig. 1 of RFC 2246, while > this proposal doesn't. > Agree so far. > This would be quite radical change to TLS. For example, the base > TLS spec assumes this state machine is always used, so either we > need to change it to accommodate GSS-API, or the GSS-API document > has to effectively overrule the base spec in many places. > > (I also believe that implementation could be easier if the state > machine is not changed, but that's probably a secondary concern.) > > >> Structurally, the problem with your proposal that has been pointed >> out to me is that many use of TLS requires authentication have to be >> established before the finished message, or it will be useless. This >> aspect needs to be analyzed to determined whether completing >> authentication before the finished message is an absolute >> requirement for a solution to be meaningful. > > Could you explain why you think it will be useless? > > We certainly have to complete the authentication (including GSS-API) > before we let application data through. In my proposal, that would > happen after the channel binding messages (not immediately after the > finished messages). This would change the same state machine which you reference in RFC 2246. That figure makes it clear that application data immediately follows the Finished message. Inserting more handshake messages between the Finished message and the application data is just as big a change as is inserting them before the Finished message. Both the GSSAPI draft and the TEE draft add handshake messages before the Finished message. To require further authentication or keying messages after the Finished message would alter the meaning of the Finished message. Maybe we should rename it to AlmostFinished. I suggest that rather than conducting a straw poll about whether or not GSSAPI (or TEE) should become working group items, we first have one on whether external authentication should become a working group item. If the answer to that is yes, we can then discuss whether we should use the RADIUS namespace, EAP or GSSAPI. Regards, Yoav _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 10:06: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 1HU1QM-0002xN-Mo; Wed, 21 Mar 2007 10:04:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1QK-0002xG-Vo for tls@ietf.org; Wed, 21 Mar 2007 10:04:20 -0400 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1QG-0002yT-3Q for tls@ietf.org; Wed, 21 Mar 2007 10:04:20 -0400 Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 28E39BFA2; Wed, 21 Mar 2007 14:04:02 +0000 (GMT) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 49E0476612C; Wed, 21 Mar 2007 10:03:51 -0400 (EDT) Date: Wed, 21 Mar 2007 10:03:51 -0400 From: "Steven M. Bellovin" To: EKR Subject: Re: [TLS] Re: AES-GCM drafts as WG items In-Reply-To: <861wjk10r7.fsf@delta.rtfm.com> References: <87hcsgukg1.fsf@mocca.josefsson.org> <861wjk10r7.fsf@delta.rtfm.com> Organization: Columbia University X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.7; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070321140351.49E0476612C@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Simon Josefsson , 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, 20 Mar 2007 06:51:40 -0700 EKR wrote: > > > Btw, SHA-2 is patented by NSA, but they have not yet filed the > > required disclosure to the IETF. > > I was not aware of this. The usual procedure is for someone to file > a 3rd party disclosure and then the secretariat will contact > the patent holder... > I've been working with NIST to get a statement from NSA. Thus far, they've said nothing, but I was told it would take a while. I should note that from historical precedent, there's virtually no chance that NSA would impose any conditions -- they *want* it widely used. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 10:38: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 1HU1wC-00036y-TZ; Wed, 21 Mar 2007 10:37:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1wC-00036Z-7H for tls@ietf.org; Wed, 21 Mar 2007 10:37:16 -0400 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1w0-00038Z-SN for tls@ietf.org; Wed, 21 Mar 2007 10:37:16 -0400 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 21 Mar 2007 14:37:04 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Wed, 21 Mar 2007 14:37:03 +0000 From: Stefan Santesson To: "tls@ietf.org" Date: Wed, 21 Mar 2007 14:36:59 +0000 Thread-Topic: TLS state machine Thread-Index: Acdrmne2RMU/t9AmTX6wMCdScj6wAQAKvL4A Message-ID: References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com> <33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> In-Reply-To: <33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [TLS] TLS state machine 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 have had lots of discussions around GSS-TLS ending in arguments that thi= s would do too many changes to the TLS state machine. It would be a lot easier to hold that discussion constructively if the TLS = state machine was clearly described. A search for the term "state machine" = in current TLS 1.2 returns empty. I can't find any other text that would cl= early resemble such description. Would it be possible to add an annex in TLS 1.2 describing the TLS state ma= chine? It would then be a lot easier to analyze and discuss the impact of any chan= ges caused by various usages of the TLS extensibility mechanisms. Stefan Santesson Senior Program Manager Windows Security, Standards _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 11:09:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU2Pf-0004y2-2q; Wed, 21 Mar 2007 11:07:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU2Pe-0004xv-0o for tls@ietf.org; Wed, 21 Mar 2007 11:07:42 -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 1HU2PM-0001JO-Kb for tls@ietf.org; Wed, 21 Mar 2007 11:07:42 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2LF7D1J005262; Wed, 21 Mar 2007 17:07:22 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 17:07:20 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 17:07:19 +0200 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] TLS state machine Date: Wed, 21 Mar 2007 17:07:18 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS state machine Thread-Index: Acdrmne2RMU/t9AmTX6wMCdScj6wAQAKvL4AAADUQ8A= References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com><33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> From: To: , X-OriginalArrivalTime: 21 Mar 2007 15:07:19.0750 (UTC) FILETIME=[9EF0DE60:01C76BCA] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070321170722-0C5E4BB0-6200BEB8/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 The state machine is (sort of implicitly) described in these two figures, copied from RFC 4346: ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data And the session resumption case: ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data I'm not sure if using a state machine description language would actually help understanding, but it could look something like this (server's initial state): State: WAITING_FOR_CLIENT_HELLO=20 Event: ClientHello received process the client hello if (didn't work out) send alert next state: FAILED else if (session being resumed) =20 send ServerHello, ChangeCipherSpec, Finished next state: WAITING_FOR_CCS else send ServerHello [Certificate] [ServerKeyExchange]=20 [CertificateRequest] ServerHelloDone next state: WAITING_FOR_CERT_OR_CLIENT_KEY_EXCHANGE Event: anything else maybe send alert go to state FAILED (The TLS implementations I've taken a look at actually have code that resembles this.) Best regards, Pasi=20 > -----Original Message----- > From: ext Stefan Santesson [mailto:stefans@microsoft.com]=20 > Sent: 21 March, 2007 16:37 > To: tls@ietf.org > Subject: [TLS] TLS state machine >=20 > We have had lots of discussions around GSS-TLS ending in=20 > arguments that this would do too many changes to the TLS=20 > state machine. >=20 > It would be a lot easier to hold that discussion=20 > constructively if the TLS state machine was clearly=20 > described. A search for the term "state machine" in current=20 > TLS 1.2 returns empty. I can't find any other text that would=20 > clearly resemble such description. >=20 > Would it be possible to add an annex in TLS 1.2 describing=20 > the TLS state machine? >=20 > It would then be a lot easier to analyze and discuss the=20 > impact of any changes caused by various usages of the TLS=20 > extensibility mechanisms. >=20 >=20 > Stefan Santesson > Senior Program Manager > Windows Security, Standards _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 11:18: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 1HU2ZA-0004zz-RQ; Wed, 21 Mar 2007 11:17:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU2Z8-0004zo-Vb for tls@ietf.org; Wed, 21 Mar 2007 11:17:31 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU2Yz-0003Uy-BR for tls@ietf.org; Wed, 21 Mar 2007 11:17:30 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2LFH27q003243; Wed, 21 Mar 2007 17:17:16 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 17:16:56 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 17:16:56 +0200 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] Review of draft-santesson-tls-gssapi-00 Date: Wed, 21 Mar 2007 17:16:57 +0200 Message-ID: In-Reply-To: <33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdrmqOaSsjASPM9RQGGsVNbIzqsgAAMApSA References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com> <33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> From: To: X-OriginalArrivalTime: 21 Mar 2007 15:16:56.0469 (UTC) FILETIME=[F6B13450:01C76BCB] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070321171716-052EDBB0-7A1E06EA/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 Yoav Nir wrote: > > We certainly have to complete the authentication (including GSS-API) > > before we let application data through. In my proposal, that would > > happen after the channel binding messages (not immediately after the > > finished messages). >=20 > This would change the same state machine which you reference in RFC =20 > 2246. That figure makes it clear that application data immediately =20 > follows the Finished message. Inserting more handshake messages =20 > between the Finished message and the application data is just as big =20 > a change as is inserting them before the Finished message. In my proposal, the GSS-API messages would use a new content type, not handshake; so the state machine for TLS handshake message processing would not be changed. IMHO this is a smaller change (but I admit that judging the size of these changes is somewhat subjective). > I suggest that rather than conducting a straw poll about whether or =20 > not GSSAPI (or TEE) should become working group items, we first have =20 > one on whether external authentication should become a working group =20 > item. If the answer to that is yes, we can then discuss whether we =20 > should use the RADIUS namespace, EAP or GSSAPI. To even consider a straw poll about TEE, you need to present a plausible plan on how to revise the EAP applicability statement (which will not happen in TLS WG, but somewhere else) that is acceptable to the EAP community and SEC ADs. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 11:49: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 1HU32f-0006B8-1P; Wed, 21 Mar 2007 11:48:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU32d-00065X-Hi for tls@ietf.org; Wed, 21 Mar 2007 11:47:59 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU32c-0001tx-4K for tls@ietf.org; Wed, 21 Mar 2007 11:47:59 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2LFlQ2w022776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 16:47:27 +0100 From: Simon Josefsson To: References: <200703081752.SAA13445@uw1048.wdf.sap.corp> <861wjyfnmp.fsf@delta.rtfm.com> <86fy8ee7g5.fsf@delta.rtfm.com> <33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070321:tls@ietf.org::adOWHPURszeJNBjI:nO1 X-Hashcash: 1:22:070321:ynir@checkpoint.com::JOfKCTZyx0ZoRLDv:3f1q X-Hashcash: 1:22:070321:pasi.eronen@nokia.com::wQnlHLDgiaT0xuGs:TKhX Date: Wed, 21 Mar 2007 16:47:26 +0100 In-Reply-To: (Pasi Eronen's message of "Wed\, 21 Mar 2007 17\:16\:57 +0200") Message-ID: <87ejnippip.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.8 required=4.0 tests=AWL,BAYES_40, 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.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tls@ietf.org Subject: [TLS] Re: Review of draft-santesson-tls-gssapi-00 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 writes: > Yoav Nir wrote: > >> > We certainly have to complete the authentication (including GSS-API) >> > before we let application data through. In my proposal, that would >> > happen after the channel binding messages (not immediately after the >> > finished messages). >> >> This would change the same state machine which you reference in RFC >> 2246. That figure makes it clear that application data immediately >> follows the Finished message. Inserting more handshake messages >> between the Finished message and the application data is just as big >> a change as is inserting them before the Finished message. > > In my proposal, the GSS-API messages would use a new content type, not > handshake; so the state machine for TLS handshake message processing > would not be changed. > > IMHO this is a smaller change (but I admit that judging the size of > these changes is somewhat subjective). I like your proposal better too, since it seems like a good compromise here, but I believe one of the problems with it is termination: if the TLS handshake Finished messages doesn't complete a TLS handshake, from a key-management point of view (which is what some applications wants from TLS), when should the TLS session terminate? With your proposal it finishes after TLS Finished and after GSS_Init/Accept_sec_context terminates with success. That's not a generic termination condition that fits well with how EAP looks at TLS negotiation. A generic "user authentication" mechanism like the TLS Inner Application extension, enhanced with support for GSS-API, may be better. It would provide a framework to tell applications using TLS for key-management when the TLS negotiations have finished, instead of having them wait for TLS Finished and then wait for GSS success. Anyway, I'd be interested to hear EKR and Stefan's thoughts on your proposal, and what (if any) disadvantages they believe it have. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 12:57: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 1HU46R-0006vc-Ut; Wed, 21 Mar 2007 12:56:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU46O-0006fo-Rl for tls@ietf.org; Wed, 21 Mar 2007 12:55:56 -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 1HU46L-0006Vh-Ef for tls@ietf.org; Wed, 21 Mar 2007 12:55:56 -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.685.24; Wed, 21 Mar 2007 09:55: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.685.25; Wed, 21 Mar 2007 09:55: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.3953); Wed, 21 Mar 2007 09:55:50 -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] Review of draft-santesson-tls-gssapi-00 Date: Wed, 21 Mar 2007 09:55:48 -0700 Message-ID: <802A881C87166D4597F9EEFC3F04F4F80468C8EE@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdrmqOaSsjASPM9RQGGsVNbIzqsgAAMApSAAAOR2OA= References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com><33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> From: Ari Medvinsky To: , X-OriginalArrivalTime: 21 Mar 2007 16:55:50.0299 (UTC) FILETIME=[C787CEB0:01C76BD9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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, I have two objections to the proposal of doing a GSS exchange after the finished msgs: 1) Numerous existing applications expect to know the identity of the client upon completion of the handshake (e.g., consider https for existing web servers, there lots of other examples); your proposal would require major overhaul to the way apps are secured today with TLS 2) Your proposal still requires the server to have an X509 certificate; the original proposal does not have this constraint. There are scenarios where it is desirable not require server to have an SSL cert. Ari Medvinsky Sr. Program Manager Windows Security -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Wednesday, March 21, 2007 8:17 AM To: ynir@checkpoint.com Cc: tls@ietf.org Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00 Yoav Nir wrote: > > We certainly have to complete the authentication (including GSS-API) > > before we let application data through. In my proposal, that would > > happen after the channel binding messages (not immediately after the > > finished messages). >=20 > This would change the same state machine which you reference in RFC =20 > 2246. That figure makes it clear that application data immediately =20 > follows the Finished message. Inserting more handshake messages =20 > between the Finished message and the application data is just as big =20 > a change as is inserting them before the Finished message. In my proposal, the GSS-API messages would use a new content type, not handshake; so the state machine for TLS handshake message processing would not be changed. IMHO this is a smaller change (but I admit that judging the size of these changes is somewhat subjective). > I suggest that rather than conducting a straw poll about whether or =20 > not GSSAPI (or TEE) should become working group items, we first have =20 > one on whether external authentication should become a working group =20 > item. If the answer to that is yes, we can then discuss whether we =20 > should use the RADIUS namespace, EAP or GSSAPI. To even consider a straw poll about TEE, you need to present a plausible plan on how to revise the EAP applicability statement (which will not happen in TLS WG, but somewhere else) that is acceptable to the EAP community and SEC ADs. Best regards, Pasi _______________________________________________ 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 Mar 21 13: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 1HU4J4-0006Pj-8q; Wed, 21 Mar 2007 13:09:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4J2-0006PX-KF for tls@ietf.org; Wed, 21 Mar 2007 13:09:00 -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 1HU4J1-00018u-5m for tls@ietf.org; Wed, 21 Mar 2007 13:09:00 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2LH8r54024316; Wed, 21 Mar 2007 19:08:57 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 19:08:56 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 19:08:56 +0200 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] Review of draft-santesson-tls-gssapi-00 Date: Wed, 21 Mar 2007 19:08:53 +0200 Message-ID: In-Reply-To: <802A881C87166D4597F9EEFC3F04F4F80468C8EE@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdrmqOaSsjASPM9RQGGsVNbIzqsgAAMApSAAAOR2OAAAFr64A== References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com><33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> <802A881C87166D4597F9EEFC3F04F4F80468C8EE@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> From: To: , X-OriginalArrivalTime: 21 Mar 2007 17:08:56.0314 (UTC) FILETIME=[9C082DA0:01C76BDB] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Ari Medvinsky wrote: >=20 > Pasi, >=20 > I have two objections to the proposal of doing a GSS exchange=20 > after the finished msgs: > 1) Numerous existing applications expect to know the identity of the > client upon completion of the handshake (e.g., consider https for > existing web servers, there lots of other examples); your proposal > would require major overhaul to the way apps are secured today with > TLS I'm not sure if I understand this concern. Certainly a TLS library doing GSS-API would tell the application "handshake completed" only after the GSS-API part was also completed? > 2) Your proposal still requires the server to have an X509 > certificate; the original proposal does not have this constraint. > There are scenarios where it is desirable not require server to have > an SSL cert. I agree that we don't want to require server certs. While the rough=20 sketch in my earlier message did " TLS_RSA_GSSAPI_WITH_...", it would work exactly the same way for "TLS_DH_anon_GSSAPI_WITH...". So a server cert is not needed. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 13:16: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 1HU4PK-0000sw-2H; Wed, 21 Mar 2007 13:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4PI-0000rn-P8 for tls@ietf.org; Wed, 21 Mar 2007 13:15:28 -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 1HU4PG-0002mF-BK for tls@ietf.org; Wed, 21 Mar 2007 13:15:28 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2LHF8PC027826; Wed, 21 Mar 2007 19:15:24 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 19:15:14 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 19:15:14 +0200 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, 21 Mar 2007 19:15:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF68 TLS WG summary Thread-Index: Acdr3HxcKpvCl9umRca9NcP7xrskqQ== From: To: , X-OriginalArrivalTime: 21 Mar 2007 17:15:14.0413 (UTC) FILETIME=[7D6581D0:01C76BDC] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [TLS] IETF68 TLS WG summary X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pasi.Eronen@nokia.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 Transport Layer Security (TLS) working group met on Tuesday morning. The main topic was TLS 1.2, which is progressing (although missing some milestones). We discussed how to best handle algorithm agility for signatures (in certificates and certain TLS messages), what to=20 say about algorithm identifier parameters, and alert messages. Eric and Joe Salowey presented drafts that add AES-GCM cipher suites to TLS 1.2, one document containing RSA key exchange and the other "Suite B" compliant ECC suites. There was consensus to adopt both as WG documents (subject to confirmation on the list). There was also some desire to have clear rules when to adopt algorithm and/or profile documents as WG items, so that similar documents backed by other national governments would be treated fairly. The chairs promised to make a first proposal for rules. Yaron Sheffer gave a presentation on adding EAP authentication TLS. This is not consistent with current EAP applicability statement, and changing it needs more discussion with EAP community. There was some interest from e.g. SSL VPN community. GSS-API authentication for TLS was not presented, but it was observed that there are similarities to EAP work. WG seemed to have interest in this work, and discussion will continue on the list. Eric gave a presentation on using TLS to derive keys for other uses than TLS record layer (such as SRTP and SCTP). This seems desirable, but needs to consider other parts of security association than just the key. As few people had read the draft, this will continue as an individual draft for now. Best regards, Pasi & Eric _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 13:35: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 1HU4hS-0002r2-5o; Wed, 21 Mar 2007 13:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU4hR-0002qL-9f for tls@ietf.org; Wed, 21 Mar 2007 13:34:13 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU4hP-0006qE-Ks for tls@ietf.org; Wed, 21 Mar 2007 13:34:13 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2LHXtcf008018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 18:33:57 +0100 From: Simon Josefsson To: References: <200703081752.SAA13445@uw1048.wdf.sap.corp> <861wjyfnmp.fsf@delta.rtfm.com> <86fy8ee7g5.fsf@delta.rtfm.com> <33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> <802A881C87166D4597F9EEFC3F04F4F80468C8EE@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070321:tls@ietf.org::DWwm7kp6Bl53GQfs:0BdlU X-Hashcash: 1:22:070321:pasi.eronen@nokia.com::BGLiOvOjHc4hOj39:MtFy X-Hashcash: 1:22:070321:arimed@windows.microsoft.com::CdqsufjdjC2JynSG:WKAy Date: Wed, 21 Mar 2007 18:33:55 +0100 In-Reply-To: (Pasi Eronen's message of "Wed\, 21 Mar 2007 19\:08\:53 +0200") Message-ID: <87odmmo60s.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-1.3 required=4.0 tests=AWL,BAYES_05, 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.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: arimed@windows.microsoft.com, tls@ietf.org Subject: [TLS] Re: Review of draft-santesson-tls-gssapi-00 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 writes: > Ari Medvinsky wrote: >> >> Pasi, >> >> I have two objections to the proposal of doing a GSS exchange >> after the finished msgs: >> 1) Numerous existing applications expect to know the identity of the >> client upon completion of the handshake (e.g., consider https for >> existing web servers, there lots of other examples); your proposal >> would require major overhaul to the way apps are secured today with >> TLS > > I'm not sure if I understand this concern. Certainly a TLS library > doing GSS-API would tell the application "handshake completed" > only after the GSS-API part was also completed? I'm not convinced of that. It is useful for TLS library APIs to be consistent with the TLS protocol. Your proposal was to add the GSS-API negotiation after the TLS handshake. What this means in practice is that, to speak in library-specific API terms, that applications after calling gnutls_handshake() will have to call gnutls_gssapi_handshake(). This is similar to what we did for TLS/IA, after gnutls_handshake() the application calls gnutls_ia_handshake() to perform the inner handshake. Only once both calls have finished successfully will the application be satisfied. I disagree that this is a serious problem. Yes, both TLS libraries and applications must be changed, but they need to be changed to support this functionality anyway. The changes inherent in Pasi's proposal aren't that much bigger than those in Stefan's original proposal. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 14:12: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 1HU5H6-00079p-Ty; Wed, 21 Mar 2007 14:11:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5Gc-0006HD-OQ for tls@ietf.org; Wed, 21 Mar 2007 14:10:34 -0400 Received: from ms-smtp-04.rdc-nyc.rr.com ([24.29.109.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5BP-0000of-BP for tls@ietf.org; Wed, 21 Mar 2007 14:05:13 -0400 Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-04.rdc-nyc.rr.com (8.13.4/8.13.4) with ESMTP id l2LI5AXW021243 for ; Wed, 21 Mar 2007 14:05:10 -0400 (EDT) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.6) with ESMTP id md50000047514.msg for ; Wed, 21 Mar 2007 14:05:57 -0400 Message-ID: <46017405.7050302@secure-endpoints.com> Date: Wed, 21 Mar 2007 14:05:57 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: simon@josefsson.org Subject: Re: [TLS] Re: Review of draft-santesson-tls-gssapi-00 References: <200703081752.SAA13445@uw1048.wdf.sap.corp> <861wjyfnmp.fsf@delta.rtfm.com> <86fy8ee7g5.fsf@delta.rtfm.com> <33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> <802A881C87166D4597F9EEFC3F04F4F80468C8EE@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> <87odmmo60s.fsf@mocca.josefsson.org> In-Reply-To: <87odmmo60s.fsf@mocca.josefsson.org> X-Enigmail-Version: 0.94.3.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Wed, 21 Mar 2007 14:05: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.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: arimed@windows.microsoft.com, 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="===============2015179878==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============2015179878== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070203080003020208070601" This is a cryptographically signed message in MIME format. --------------ms070203080003020208070601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Simon Josefsson wrote: > I'm not convinced of that. It is useful for TLS library APIs to be > consistent with the TLS protocol. Your proposal was to add the > GSS-API negotiation after the TLS handshake. I believe that by negotiating TLS_XXX_GSS_YYY it is implicit that the TLS library API must not return until after the GSS handshake has completed. Otherwise, what is the point of adding the new cipher suite designator? Jeffrey Altman --------------ms070203080003020208070601 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 AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAzMjExODA1NTdaMCMGCSqGSIb3DQEJBDEWBBQj0vCg udyOFJohEK0uqohkmkIyuDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAl+OKvQX3caPt/XYngo967+SxLn9hCDtCs3GnZrOoL3CS74mHEaO2 kTW6rOIu3N/j6NYpFXd4NJzjhwd4MRsV4li/6e0bEJJFpnhThuyKM4Qc1jJNQppSA+yNvzxH lXESJs5GCESvmnaobdLwlE4cVo4/5GvW51uM/A5m1W0cmjRnJuv8yQaQoKmZ0C0QImcf9KXC CZhDYhq95AJZXTLW+5+QQknIJNkrp6rbNAy6MpAcmaqdy0YaA2OZmu5I/wR4CiTKo9PX17t5 K68crsLxrtl7LzJmzxUn2OXCrZbX1xthS6eBDHotaxUKpF1sBugq7rYBQa38drIAcZ9NV8YA 3wAAAAAAAA== --------------ms070203080003020208070601-- --===============2015179878== 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 --===============2015179878==-- From tls-bounces@lists.ietf.org Wed Mar 21 14:19: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 1HU5Oc-0004nc-VL; Wed, 21 Mar 2007 14:18:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5Ob-0004nS-ED for tls@ietf.org; Wed, 21 Mar 2007 14:18:49 -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 1HU5OY-0004qd-0J for tls@ietf.org; Wed, 21 Mar 2007 14:18:49 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2LIIFsV016581; Wed, 21 Mar 2007 20:18:42 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 20:18:40 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 20:18:40 +0200 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, 21 Mar 2007 20:18:39 +0200 Message-ID: In-Reply-To: <87odmmo60s.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-santesson-tls-gssapi-00 Thread-Index: Acdr3yZ9VVGITrzOS1elQAxYUJf9GwABPDHA References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com><33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com><802A881C87166D4597F9EEFC3F04F4F80468C8EE@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> <87odmmo60s.fsf@mocca.josefsson.org> From: To: , X-OriginalArrivalTime: 21 Mar 2007 18:18:40.0472 (UTC) FILETIME=[59FC0580:01C76BE5] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: arimed@windows.microsoft.com Subject: [TLS] RE: Review of draft-santesson-tls-gssapi-00 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: > > I'm not sure if I understand this concern. Certainly a TLS library > > doing GSS-API would tell the application "handshake completed" > > only after the GSS-API part was also completed? >=20 > I'm not convinced of that. It is useful for TLS library APIs to be > consistent with the TLS protocol. Your proposal was to add the > GSS-API negotiation after the TLS handshake. Well, Stefan's draft is about adding GSS-API based authentication to TLS; my proposal was simply to rearrange the message order (and adjust some other details like message types and exactly how the crypto part works) to make it fit "nicer" with RFC 4346. Regardless of the message order (and other details), GSS-API=20 authentication becomes part of the TLS protocol. But certainly the exact message order should not have impact on the TLS library APIs. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 14:22: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 1HU5Rx-0000Sc-Os; Wed, 21 Mar 2007 14:22:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5Rw-0000SQ-TY for tls@ietf.org; Wed, 21 Mar 2007 14:22:16 -0400 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5Rv-0005qj-DM for tls@ietf.org; Wed, 21 Mar 2007 14:22:16 -0400 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 21 Mar 2007 18:22:14 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Wed, 21 Mar 2007 18:22:13 +0000 From: Stefan Santesson To: Simon Josefsson , "Pasi.Eronen@nokia.com" Date: Wed, 21 Mar 2007 18:22:10 +0000 Subject: RE: [TLS] Re: Review of draft-santesson-tls-gssapi-00 Thread-Topic: [TLS] Re: Review of draft-santesson-tls-gssapi-00 Thread-Index: Acdr36r1w2vqVmr6Qf6901cbs6VUrwABav0A Message-ID: References: <200703081752.SAA13445@uw1048.wdf.sap.corp> <861wjyfnmp.fsf@delta.rtfm.com> <86fy8ee7g5.fsf@delta.rtfm.com> <33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> <802A881C87166D4597F9EEFC3F04F4F80468C8EE@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> <87odmmo60s.fsf@mocca.josefsson.org> In-Reply-To: <87odmmo60s.fsf@mocca.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Ari Medvinsky , "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 disagree that the application need to be altered in the original proposal= . It all depends on where TLS obtains its policies and parameters. If that is= supplied by separate configuration or policy DB, then the originally propo= sed handshake can be performed transparent to the application. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Simon Josefsson [mailto:simon@josefsson.org] > Sent: den 21 mars 2007 18:34 > To: Pasi.Eronen@nokia.com > Cc: Ari Medvinsky; tls@ietf.org > Subject: [TLS] Re: Review of draft-santesson-tls-gssapi-00 > > writes: > > > Ari Medvinsky wrote: > >> > >> Pasi, > >> > >> I have two objections to the proposal of doing a GSS exchange > >> after the finished msgs: > >> 1) Numerous existing applications expect to know the identity of the > >> client upon completion of the handshake (e.g., consider https for > >> existing web servers, there lots of other examples); your proposal > >> would require major overhaul to the way apps are secured today with > >> TLS > > > > I'm not sure if I understand this concern. Certainly a TLS library > > doing GSS-API would tell the application "handshake completed" > > only after the GSS-API part was also completed? > > I'm not convinced of that. It is useful for TLS library APIs to be > consistent with the TLS protocol. Your proposal was to add the > GSS-API negotiation after the TLS handshake. > > What this means in practice is that, to speak in library-specific API > terms, that applications after calling gnutls_handshake() will have to > call gnutls_gssapi_handshake(). This is similar to what we did for > TLS/IA, after gnutls_handshake() the application calls > gnutls_ia_handshake() to perform the inner handshake. Only once both > calls have finished successfully will the application be satisfied. > > I disagree that this is a serious problem. Yes, both TLS libraries > and applications must be changed, but they need to be changed to > support this functionality anyway. The changes inherent in Pasi's > proposal aren't that much bigger than those in Stefan's original > proposal. > > /Simon > > _______________________________________________ > 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 Mar 21 14:36: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 1HU5fN-0004zR-NH; Wed, 21 Mar 2007 14:36:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5fM-0004zK-S7 for tls@ietf.org; Wed, 21 Mar 2007 14:36:08 -0400 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5fI-0000w6-76 for tls@ietf.org; Wed, 21 Mar 2007 14:36:08 -0400 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 21 Mar 2007 18:36:03 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Wed, 21 Mar 2007 18:36:02 +0000 From: Stefan Santesson To: "Pasi.Eronen@nokia.com" , "tls@ietf.org" Date: Wed, 21 Mar 2007 18:35:59 +0000 Subject: RE: [TLS] TLS state machine Thread-Topic: [TLS] TLS state machine Thread-Index: Acdrmne2RMU/t9AmTX6wMCdScj6wAQAKvL4AAADUQ8AAB4htgA== Message-ID: References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com><33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 Thank you Pasi, Considering this being the TLS state machine, the TLS extension mechanism c= learly allows a change of the TLS state machine as it allows other handshak= e messages to be inserted in this flow. What are the criteria that distinguish a valid change to the TLS state mach= ine from an invalid (unsuitable) one? Or is this totally subjective? Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: den 21 mars 2007 16:07 > To: Stefan Santesson; tls@ietf.org > Subject: RE: [TLS] TLS state machine > > > The state machine is (sort of implicitly) described in these two > figures, copied from RFC 4346: > > ClientHello --------> > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > And the session resumption case: > > ClientHello --------> > ServerHello > [ChangeCipherSpec] > <-------- Finished > [ChangeCipherSpec] > Finished --------> > Application Data <-------> Application Data > > I'm not sure if using a state machine description language would > actually help understanding, but it could look something like this > (server's initial state): > > State: WAITING_FOR_CLIENT_HELLO > Event: ClientHello received > process the client hello > if (didn't work out) > send alert > next state: FAILED > else if (session being resumed) > send ServerHello, ChangeCipherSpec, Finished > next state: WAITING_FOR_CCS > else > send ServerHello [Certificate] [ServerKeyExchange] > [CertificateRequest] ServerHelloDone > next state: WAITING_FOR_CERT_OR_CLIENT_KEY_EXCHANGE > Event: anything else > maybe send alert > go to state FAILED > > (The TLS implementations I've taken a look at actually have code > that resembles this.) > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Stefan Santesson [mailto:stefans@microsoft.com] > > Sent: 21 March, 2007 16:37 > > To: tls@ietf.org > > Subject: [TLS] TLS state machine > > > > We have had lots of discussions around GSS-TLS ending in > > arguments that this would do too many changes to the TLS > > state machine. > > > > It would be a lot easier to hold that discussion > > constructively if the TLS state machine was clearly > > described. A search for the term "state machine" in current > > TLS 1.2 returns empty. I can't find any other text that would > > clearly resemble such description. > > > > Would it be possible to add an annex in TLS 1.2 describing > > the TLS state machine? > > > > It would then be a lot easier to analyze and discuss the > > impact of any changes caused by various usages of the TLS > > extensibility mechanisms. > > > > > > Stefan Santesson > > Senior Program Manager > > Windows Security, Standards _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 19:11: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 1HU9w9-00010c-PS; Wed, 21 Mar 2007 19:09:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU9w8-00010S-Io for tls@ietf.org; Wed, 21 Mar 2007 19:09:44 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU9w7-0000H6-5r for tls@ietf.org; Wed, 21 Mar 2007 19:09:44 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id BAA21106; Thu, 22 Mar 2007 01:09:19 +0200 (MESZ) From: Martin Rex Message-Id: <200703212309.AAA25298@uw1048.wdf.sap.corp> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 To: arimed@windows.microsoft.com (Ari Medvinsky) Date: Thu, 22 Mar 2007 00:09:18 +0100 (MET) In-Reply-To: <802A881C87166D4597F9EEFC3F04F4F80468C8EE@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> from "Ari Medvinsky" at Mar 21, 7 09:55:48 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-SAP: out X-Spam-Score: 0.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 Ari Medvinsky wrote: > > I have two objections to the proposal of doing a GSS exchange after the > finished msgs: > 1) Numerous existing applications expect to know the identity of the > client upon completion of the handshake (e.g., consider https for > existing web servers, there lots of other examples); your proposal would > require major overhaul to the way apps are secured today with TLS I completely disagree. If you're doing the abstraction correctly, it will be transparent for the existing web-servers. You will need to insert an additional "tls-gss" layer on top of TLS which does all the GSS-API wizardry, provides the TLS stack with the necessary tokens for the mech oid negotiation and supplies the gssapi context level tokens for the context establishment following the TLS finished exchange. This tls-gss layer might persist GSS-API status/context information and provide access to things like authorization data. You really don't want to go all the way through the TLS layers to frob with gssapi features and extensions. Unless a severely broken application looks at the bits-on-the-wire, it doesn't know and doesn't care where exactly the finished message goes on the wire. The App can (and SHOULD) only react to API return codes tell the application "TLS handshake complete" -- and the tls-gss layer on top of TLS will indicate "finished" when it is done with the gssapi handshake, which is all what the web-server above will see and care about. GSS-API was designed as a token-based protocol that can be inserted into existing protocol stacks where it fits best. Since GSS-API authentication is something that the application cares about (TLS doesn't and shouldn't care about this), the gss-api authentication exchange should be layered on top. > > 2) Your proposal still requires the server to have an X509 certificate; > the original proposal does not have this constraint. There are > scenarios where it is desirable not require server to have an SSL cert. Personally, I'd really like to see a requirement for an X.509 server cert, because this is what will provide interopability with older TLS clients that don't support this extension. It should be up to the application to decide whether it can or wants to provide alternative authentication methods if GSS-API based authentication is not available. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 19:22: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 1HUA85-0002aX-Vs; Wed, 21 Mar 2007 19:22:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUA84-0002aQ-Qo for tls@ietf.org; Wed, 21 Mar 2007 19:22:04 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUA81-0002nM-Dy for tls@ietf.org; Wed, 21 Mar 2007 19:22:04 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id BAA04153; Thu, 22 Mar 2007 01:21:47 +0200 (MESZ) From: Martin Rex Message-Id: <200703212321.AAA25642@uw1048.wdf.sap.corp> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 To: arimed@windows.microsoft.com (Ari Medvinsky) Date: Thu, 22 Mar 2007 00:21:47 +0100 (MET) In-Reply-To: <802A881C87166D4597F9EEFC3F04F4F80468C8EE@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> from "Ari Medvinsky" at Mar 21, 7 09:55:48 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-SAP: out 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 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 Ari Medvinsky wrote: > > 2) Your proposal still requires the server to have an X509 certificate; > the original proposal does not have this constraint. There are > scenarios where it is desirable not require server to have an SSL cert. If at all, the architecture should address GSS-API in general, not just specific mechanisms favoured by a few. SSL/TLS has been around for >10 years, so providing web servers with an X.509 cert is a long solved problem. The reason why gssapi authentication is interesting is because it would allow one to authenticate clients/users based on their existing (non-X.509) credentials in order to provide Single Sign-On. Since the installed base does not yet implement a tls-gss extension (heck, we don't even know what it is going to look like), we ought to provide a migration path instead of a flag day, so that clients that are later in supporting tls-gss can still interoperate based on existing authentication schemes, and ultimately that means the server ought to provide an X.509 cert for quite some time. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 19:38: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 1HUANU-0006cO-Ta; Wed, 21 Mar 2007 19:38:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUANT-0006at-8T for tls@ietf.org; Wed, 21 Mar 2007 19:37:59 -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 1HUANS-0005yh-0V for tls@ietf.org; Wed, 21 Mar 2007 19:37:59 -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 l2LNbvNE013608 for ; Wed, 21 Mar 2007 18:37:57 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.6) with ESMTP id md50000047574.msg for ; Wed, 21 Mar 2007 19:38:44 -0400 Message-ID: <4601C200.3080105@secure-endpoints.com> Date: Wed, 21 Mar 2007 19:38:40 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: martin.rex@sap.com Subject: Re: [***SPAM*** Score/Req: 11.0/5.0] Re: [TLS] Review of draft-santesson-tls-gssapi-00 References: <200703212321.AAA25642@uw1048.wdf.sap.corp> In-Reply-To: <200703212321.AAA25642@uw1048.wdf.sap.corp> X-Enigmail-Version: 0.94.3.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Wed, 21 Mar 2007 19:38:44 -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.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Ari Medvinsky , 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="===============1613490297==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1613490297== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090602060304010001040707" This is a cryptographically signed message in MIME format. --------------ms090602060304010001040707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin Rex wrote: > Ari Medvinsky wrote: >> 2) Your proposal still requires the server to have an X509 certificate; >> the original proposal does not have this constraint. There are >> scenarios where it is desirable not require server to have an SSL cert. > > If at all, the architecture should address GSS-API in general, > not just specific mechanisms favoured by a few. > > SSL/TLS has been around for >10 years, so providing web servers with an > X.509 cert is a long solved problem. The reason why gssapi authentication > is interesting is because it would allow one to authenticate clients/users > based on their existing (non-X.509) credentials in order to provide > Single Sign-On. > > Since the installed base does not yet implement a tls-gss extension > (heck, we don't even know what it is going to look like), we ought > to provide a migration path instead of a flag day, so that clients > that are later in supporting tls-gss can still interoperate based > on existing authentication schemes, and ultimately that means > the server ought to provide an X.509 cert for quite some time. > > -Martin Martin: There is a small but significant deployed base of RFC 2712 TLS_KRB5 implementations which need to migrate to something that is non-DES based. TLS_GSS will provide that for them immediately without the need for an X.509 certificate. They are not using an X.509 certificate with TLS_KRB5 ciphers. A TLS_GSS using Kerberos 5 would be a transparent replacement for these clients and servers when both sides support TLS_GSS instead of TLS_KRB5. Jeffrey Altman Secure Endpoints Inc. --------------ms090602060304010001040707 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 AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAzMjEyMzM4NDBaMCMGCSqGSIb3DQEJBDEWBBSk8f3u GynOWEhFxuQ14wXyF90VDTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAlt5l7EZUaioaK9DoMLtYDTXq1oURm382itgIX7Pd+lH7ZZA2uSOE ESnDkQNO8Rkst/NcTdSDPMJWNppM6wIjX0LzBuL19kM8T6VhAZ3dg3keo1RB5BDSIoVXHNJa IvfQsbJILd3ksT9PMssT2BiPPrHBflBySdcsgYOzs8OBu0UkFdrFt+F75dDaqI8Blz4KMs1q PQv4YBbou/2oacB6MXgDrTU+c4BN09l12HPMsrIxiVNqGZvnd7zdapEdqWhtyV3U6eq9Q0Q0 X93f5GN5H9aML6/35J1dnv6NVf8FckOfIySNrb4zOYDKgGMDaSGYYZUktaUpdEn60TsOCkjB /gAAAAAAAA== --------------ms090602060304010001040707-- --===============1613490297== 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 --===============1613490297==-- From tls-bounces@lists.ietf.org Wed Mar 21 19:55: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 1HUAde-00048o-OQ; Wed, 21 Mar 2007 19:54:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUAdd-00048d-C9 for tls@ietf.org; Wed, 21 Mar 2007 19:54:41 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUAdb-00014p-Ul for tls@ietf.org; Wed, 21 Mar 2007 19:54:41 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id BAA23183; Thu, 22 Mar 2007 01:54:36 +0200 (MESZ) From: Martin Rex Message-Id: <200703212354.AAA26346@uw1048.wdf.sap.corp> Subject: Re: [TLS] Re: Review of draft-santesson-tls-gssapi-00 To: stefans@microsoft.com (Stefan Santesson) Date: Thu, 22 Mar 2007 00:54:36 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Mar 21, 7 06:22:10 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: 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 Stefan Santesson wrote: > > I disagree that the application need to be altered in the original proposal. > > It all depends on where TLS obtains its policies and parameters. > If that is supplied by separate configuration or policy DB, then the > originally proposed handshake can be performed transparent to the > application. With a clean design, you'll have to alter the application. A very short-sighted approach might work with some major hacks in some environments. Keep in mind that GSS-API abstraction normally means "authentication of a communication peer", and there is no requirement that this peer is anyhow related to user accounts of the local OS. A clean architecture would ultimately allow binary plug-n-play of the gssapi mechanism with the TLS stack. And since it is not know in advance what fancy gssapi extensions the mechanism will have, what the names will look like and wether or how gssapi state could be persisted, the TLS stack should NOT sit between the gssapi mechanism and the application, but underneath the gssapi mechanism. GSS-API state may include alternative names, authorization data and that information may be entirely independent (or incompatible) with the native-OS means to represent such data. If someone says "In my scenario I could do it transparently", then he might be thinking with an extremely narrow focus and not sufficiently general for the architecture of the protocols at hand (TLS,GSS-API). Another issue: TLS session can be cached and can be "forked". In fact, it is common practice to "fork" TLS sessions frequently. GSS-API security contexts, on the other hand, can not normally be duplicated. And quite a lot of gssapi mechanism require/enforce a strictly sequential stream of protected messages (which is how they provide data replay protection). I really don't want to see the TLS stack being bothered with persisting state from the GSS-API authentication beyond a (flat) peer name. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Mar 21 20:35: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 1HUBGE-0004qN-Tq; Wed, 21 Mar 2007 20:34:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUBGE-0004oM-Be for tls@ietf.org; Wed, 21 Mar 2007 20:34:34 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUBGC-0001QS-Rb for tls@ietf.org; Wed, 21 Mar 2007 20:34:34 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id CAA05294; Thu, 22 Mar 2007 02:34:27 +0200 (MESZ) From: Martin Rex Message-Id: <200703220034.BAA27299@uw1048.wdf.sap.corp> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 To: simon@sxw.org.uk (Simon Wilkinson) Date: Thu, 22 Mar 2007 01:34:26 +0100 (MET) In-Reply-To: from "Simon Wilkinson" at Mar 21, 7 11:17:30 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: arimed@windows.microsoft.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 Simon Wilkinson wrote: > > On 21 Mar 2007, at 23:09, Martin Rex wrote: > >> le not require server to have an SSL cert. > > > > Personally, I'd really like to see a requirement for an X.509 server > > cert, because this is what will provide interopability with older > > TLS clients that don't support this extension. It should be up > > to the application to decide whether it can or wants to provide > > alternative authentication methods if GSS-API based authentication > > is not available. > > This would seem to be directly comparable to the SSH GSSAPI Key > Exchange case. One of the reasons I may want to deploy GSSAPI in TLS > is that I don't want the hassle of having to provide SSL certificates > to all of my web servers when I've got a perfectly good key > management system already deployed. In the same way as I can choose > not to provide my hosts with SSH host keys, with the knowledge that > this will cause non GSSAPI mechanisms to fail, I should be able to > make the same decision for TLS. It should be possible to optionally > provide a certificate for fallback, but not required. I think "a server certificate issue" is an exxageration. Technically, a newly generated self-signed server certificate could be used. Do we really need a new set of ciphersuites to accomodate tls-gss? (and another set for tls-eap, and another for tls-xyz,...) Having TLS negotiate (actually select) a common gssapi mechanism (OID) through a hello extension might carry sufficient information to know whether gss-api based authentication is going to be performed -- the server could either "ignore" (=not send) it when it doesn't find a match, send an empty selection, send and empty selection plus his own list of supported mechs. GSS-API mechanisms that do not (or can not) authenticate the server to the client might appreciate when an X.509 server cert is used for the original TLS handshake before the GSS-API client authentication is performed. I haven't yet heard how server-authentication is going to be performed when gss-api is used. >From the ~20 different gssapi mechanisms that have come for interoperability certification with our application during the last 9 years, only 5 implemented "hostbased service names" (only the Kerberos implementations). Not a single one of all the other gssapi mechanisms (mostly X.509/PKI-based) has implemented hostbased service names. And we shouldn't forget the GSS-API mechanisms (and their relatives like Microsoft NTLM authentication) which do not offer authentication of the server/target to the client. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Mar 22 02:06: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 1HUGOK-0000nA-NS; Thu, 22 Mar 2007 02:03:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUGOJ-0000n4-QS for tls@ietf.org; Thu, 22 Mar 2007 02:03:15 -0400 Received: from sd-green-bigip-81.dreamhost.com ([208.97.132.81] helo=randymail-a1.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUGOI-0006Y5-Hg for tls@ietf.org; Thu, 22 Mar 2007 02:03:15 -0400 Received: from delta.rtfm.com (dhcp-4009.ietf68.org [130.129.64.9]) by randymail-a1.g.dreamhost.com (Postfix) with ESMTP id 9BD2018D7BD; Wed, 21 Mar 2007 23:03:13 -0700 (PDT) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id F34491CC29; Wed, 21 Mar 2007 23:01:58 -0700 (PDT) To: jaltman@secure-endpoints.com Subject: Re: [***SPAM*** Score/Req: 11.0/5.0] Re: [TLS] Review of draft-santesson-tls-gssapi-00 In-reply-to: Your message of "Wed, 21 Mar 2007 19:38:40 EDT." <4601C200.3080105@secure-endpoints.com> X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Wed, 21 Mar 2007 23:01:58 -0700 From: EKR Message-Id: <20070322060158.F34491CC29@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Ari Medvinsky , 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: > Martin Rex wrote: > > Ari Medvinsky wrote: > >> 2) Your proposal still requires the server to have an X509 certificate; > >> the original proposal does not have this constraint. There are > >> scenarios where it is desirable not require server to have an SSL cert. > > > > If at all, the architecture should address GSS-API in general, > > not just specific mechanisms favoured by a few. > > > > SSL/TLS has been around for >10 years, so providing web servers with an > > X.509 cert is a long solved problem. The reason why gssapi authentication > > is interesting is because it would allow one to authenticate clients/users > > based on their existing (non-X.509) credentials in order to provide > > Single Sign-On. > > > > Since the installed base does not yet implement a tls-gss extension > > (heck, we don't even know what it is going to look like), we ought > > to provide a migration path instead of a flag day, so that clients > > that are later in supporting tls-gss can still interoperate based > > on existing authentication schemes, and ultimately that means > > the server ought to provide an X.509 cert for quite some time. > > > > -Martin > Martin: > > There is a small but significant deployed base of RFC 2712 TLS_KRB5 > implementations > which need to migrate to something that is non-DES based. TLS_GSS will > provide that > for them immediately without the need for an X.509 certificate. They > are not using an > X.509 certificate with TLS_KRB5 ciphers. > > A TLS_GSS using Kerberos 5 would be a transparent replacement for these > clients and > servers when both sides support TLS_GSS instead of TLS_KRB5. Sure, but as we're seeing in a number of applications, this doesn't preclude the use of self-signed certs. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Mar 22 02:26: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 1HUGkV-0007Rx-HS; Thu, 22 Mar 2007 02:26:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUGkU-0007Re-Il for tls@ietf.org; Thu, 22 Mar 2007 02:26:10 -0400 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUGfE-0002Mb-T3 for tls@ietf.org; Thu, 22 Mar 2007 02:20:49 -0400 Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id l2M6Kdul008478 for ; Thu, 22 Mar 2007 01:20:40 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.6) with ESMTP id md50000047607.msg for ; Thu, 22 Mar 2007 02:21:26 -0400 Message-ID: <46022064.70702@secure-endpoints.com> Date: Thu, 22 Mar 2007 02:21:24 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ekr@networkresonance.com Subject: Re: [***SPAM*** Score/Req: 11.0/5.0] Re: [TLS] Review of draft-santesson-tls-gssapi-00 References: <20070322060158.F34491CC29@delta.rtfm.com> In-Reply-To: <20070322060158.F34491CC29@delta.rtfm.com> X-Enigmail-Version: 0.94.3.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Thu, 22 Mar 2007 02:21:26 -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.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Ari Medvinsky , 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="===============1760515807==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1760515807== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030407010602090408030508" This is a cryptographically signed message in MIME format. --------------ms030407010602090408030508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit EKR wrote: > Jeffrey Altman wrote: > Sure, but as we're seeing in a number of applications, this doesn't > preclude the use of self-signed certs. > No it doesn't. However, as I've seen in a number of commercial and open source products, the authors don't want to go to the trouble of writing code to generate certificates as part of the install so they install the same self-signed certificate and private key on every system in the world. Most users are to naive to know how to replace the certificate, probably don't know that they should, and assume that because there is a certificate there that they are secure. One of these commercial products and its self-signed certificate was in use for many years by a major Medicare system. Self-signed certificates have their place but they should not be used as a bootstrap method for other authentication technologies. Too many people make the wrong assumptions just based upon their presence. Please do not insist that they be used as part of a TLS-GSS solution. Jeffrey Altman --------------ms030407010602090408030508 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 AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAzMjIwNjIxMjRaMCMGCSqGSIb3DQEJBDEWBBRueVRr NE+t5g/z+iv5Uv1ZlhwnkDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAej5yALFG9I+uah2e6J33Eaowr/Asz17K3h8tT6DJL5XWaz52kx87 8UBTijR/OEUl2R7yVfxpYnKulGRML0kKEW5RW6SfdKEMohCFSCGTo3GsaNfUmo9uUi9Eee0J dtOYo2rstcSf5vGskD59SA0eiavRYSceEz5C4eGryzeHo9DYFYCVL+pmwmny2KVk94nS06or wLQ0zX2Rb0FQ3uW7xHBXb/0WyQqxlGJM3Cq8wvdgTWMD62dybXBazjkHBemNiClb8MWWzAmb rXaF4PjrPhxZ8gI3A5nWlOT5iqSunXYLM/tgBswS2W3YOgl1/j6re/ddkhqs8GGphFA4FVrQ swAAAAAAAA== --------------ms030407010602090408030508-- --===============1760515807== 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 --===============1760515807==-- From tls-bounces@lists.ietf.org Thu Mar 22 04:34: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 1HUIji-0004mU-In; Thu, 22 Mar 2007 04:33:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIjh-0004mH-L8 for tls@ietf.org; Thu, 22 Mar 2007 04:33:29 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUIjd-0005Nm-8u for tls@ietf.org; Thu, 22 Mar 2007 04:33:29 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2M8X9cs006230; Thu, 22 Mar 2007 10:33:23 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 10:33:01 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 10:33:00 +0200 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] TLS state machine Date: Thu, 22 Mar 2007 10:33:01 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS state machine Thread-Index: Acdrmne2RMU/t9AmTX6wMCdScj6wAQAKvL4AAADUQ8AAB4htgAAdZGog References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com><33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> From: To: , X-OriginalArrivalTime: 22 Mar 2007 08:33:00.0954 (UTC) FILETIME=[B39CD7A0:01C76C5C] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070322103323-15DDEBB0-42FC5264/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 Stefan Santesson wrote: >=20 > Considering this being the TLS state machine, the TLS=20 > extension mechanism clearly allows a change of the TLS state=20 > machine as it allows other handshake messages to be inserted=20 > in this flow. >=20 > What are the criteria that distinguish a valid change to the=20 > TLS state machine from an invalid (unsuitable) one? > Or is this totally subjective? I wouldn't use words "valid" or "invalid" here; rather, there=20 are changes that I'd consider "nicer" (fits better with existing=20 pieces of TLS, easier to understand, simpler, etc.) than others. When there are multiple alternatives to choose from, all of which essentially work, I'd consider this "niceness" to be one important criteria for choosing between them. To some=20 degree, it is subjective; but it can also be something people can agree on (and rough WG consensus can be reached). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Mar 22 10:15: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 1HUO2k-0005yb-59; Thu, 22 Mar 2007 10:13:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUO2i-0005yW-WF for tls@ietf.org; Thu, 22 Mar 2007 10:13:29 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUO2h-0005xa-Il for tls@ietf.org; Thu, 22 Mar 2007 10:13:28 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id QAA21618; Thu, 22 Mar 2007 16:12:52 +0200 (MESZ) From: Martin Rex Message-Id: <200703221406.PAA15920@uw1048.wdf.sap.corp> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 To: jaltman@secure-endpoints.com Date: Thu, 22 Mar 2007 15:06:25 +0100 (MET) In-Reply-To: <46022064.70702@secure-endpoints.com> from "Jeffrey Altman" at Mar 22, 7 02:21:24 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-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: arimed@windows.microsoft.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: > > EKR wrote: > > Jeffrey Altman wrote: > > Sure, but as we're seeing in a number of applications, this doesn't > > preclude the use of self-signed certs. > > No it doesn't. However, as I've seen in a number of commercial and open > source products, the authors don't want to go to the trouble of > writing code to generate certificates as part of the install > so they install the same self-signed certificate and private key > on every system in the world. For an administrative UI, the generation of a new keypair should always be equal or less work than importing an existing keypair. The problem with vendors/products installing with a static/fixed keypair from the installation medium is unfortunately real. One of the reasons for this is likely shortcoming of the PKI toolkit (broken APIs) and shortcoming of the PKI toolkit documentation (it lacks examples to create self-signed credentials for common usage scenarios (e.g. SSL-Server). > > Most users are to naive to know how to replace the certificate, > probably don't know that they should, and assume that because there > is a certificate there that they are secure. One can not blame the users/customers for such a problem. Those who ship a pre-generated keypair instead freshly generating one are to blame. > > Self-signed certificates have their place but they should not be used as > a bootstrap method for other authentication technologies. I can not see anything bad about the SSH host key generation as it is designed one many Unix system today. If the server is started without a host key, it simply creates a new keypair on startup. > > Too many people make the wrong assumptions just based upon their > presence. Please do not insist that they be used as part of a TLS-GSS > solution. Please DO! Up to today TLS interoperability has been great because pretty much every server had one of the mandatory-to-implement ciphersuites available for interoperability. Making it easy or encouraging people to configure future Web-Servers with TLS_GSSAPI only ciphersuites is equal to dropping mandatory to implement ciphersuites and traditional strong interoperability of TLS will be lost forever. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Mar 22 10:26: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 1HUOE8-0008GY-V9; Thu, 22 Mar 2007 10:25:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOE8-0008Dm-AM for tls@ietf.org; Thu, 22 Mar 2007 10:25:16 -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 1HUOE6-0007nm-1d for tls@ietf.org; Thu, 22 Mar 2007 10:25:16 -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 l2MEPChS005694 for ; Thu, 22 Mar 2007 09:25:13 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.6) with ESMTP id md50000047661.msg for ; Thu, 22 Mar 2007 10:26:00 -0400 Message-ID: <460291F7.6090804@secure-endpoints.com> Date: Thu, 22 Mar 2007 10:25:59 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: martin.rex@sap.com Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 References: <200703221406.PAA15920@uw1048.wdf.sap.corp> In-Reply-To: <200703221406.PAA15920@uw1048.wdf.sap.corp> X-Enigmail-Version: 0.94.3.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Thu, 22 Mar 2007 10:26:00 -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.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: arimed@windows.microsoft.com, 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="===============1340134694==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1340134694== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020506000701070103070205" This is a cryptographically signed message in MIME format. --------------ms020506000701070103070205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin Rex wrote: > Making it easy or encouraging people to configure future Web-Servers > with TLS_GSSAPI only ciphersuites is equal to dropping > mandatory to implement ciphersuites and traditional strong interoperability > of TLS will be lost forever. The sites that have deployed RFC 2712 do not have certificates today and they want to force users to authenticate using there existing Kerberos infrastructure. Forcing the deployment of a certificate in order to deploy TLS_GSS is not going to alter the behavior of the administrators who insist that only Kerberos mutual authentication be used. Please remember that mandatory to implement does not mean mandatory to deploy. There is nothing preventing the deployment of a server that supports both TLS_GSS and certificate based ciphers that are used in most public settings. Adding complexity to the deployment of TLS_GSS is not going to alter the deployment policies of the administrators who use it. Jeffrey Altman --------------ms020506000701070103070205 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 AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAzMjIxNDI1NTlaMCMGCSqGSIb3DQEJBDEWBBRAm8TP DcYa87bhsosYLtMwH+G+NTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAWNRIl8sTyGBxUdXiPBOzHCbj+wvCLKpvRquukYxYWsvO8Qo4j7gm p3WMXht6tnLHsx3g6imBPRfM6x2aeKoOnetPkncod1Stv7W74Yf5Q1uGHBR5VLUJVQ11ItXX KJv5K/nG9em6a6NfqCjpmzvA77TVp8LSCtgWPlhGn+CocZuagH9JrwCnJd0VxM2gMNXmP6RP TwaSZjbFb6TPd2UVInSJdZMQvLwXV3AL6DS4UzoY4O4ERsS2SYSCJFmjQukeL9YZk3x4gm27 W87y4AiYclvZJu/4HE0+HX658wGc7ZKMiXgQweU+RwMBjWgb8Svn2Sf1WKmsRNAClVsODuks 9QAAAAAAAA== --------------ms020506000701070103070205-- --===============1340134694== 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 --===============1340134694==-- From tls-bounces@lists.ietf.org Thu Mar 22 11:13: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 1HUOxP-0000Dg-Dn; Thu, 22 Mar 2007 11:12:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOxN-0000D7-Rj for tls@ietf.org; Thu, 22 Mar 2007 11:12:01 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUOwn-0001jV-4t for tls@ietf.org; Thu, 22 Mar 2007 11:12:01 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1HUOwh1USq-0002BA; Thu, 22 Mar 2007 16:11:19 +0100 Received: by tau.invalid (Postfix, from userid 1000) id B109C1B60D; Thu, 22 Mar 2007 16:11:21 +0100 (CET) Date: Thu, 22 Mar 2007 16:11:21 +0100 From: Bodo Moeller To: Stefan Santesson Subject: Re: [TLS] TLS state machine Message-ID: <20070322151121.GA30669@tau.invalid> References: <20070322144814.GA28786@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070322144814.GA28786@tau.invalid> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1+mDdH3q5xAnoA++h8JCia3vJaSfU5t6nPoKHW ma9ZdWjmVc7ptnCogVBzot/TRofJNy7+7eCgaX+lho8aUayoH0 s/0sZQTdvKirVvFHxQSXQ== 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, Mar 22, 2007 at 03:48:14PM +0100, Bodo Moeller wrote: [...] > This particular concern might be cured by requiring any specific > GSS-API mechanism to provide to the TLS layer (an upper bound on) the > number of messages to be exchanged before the GSS-API portion of the > handshake actually starts. Oops, the wording I chose here turns out to be ambiguous. What I meant is: This particular concern might be cured by requiring any specific GSS-API mechanism to provide to the TLS layer, before the GSS-API portion of the handshake actually starts, (an upper bound on) the number of messages to be exchanged. > Then you could have the TLS layer do a > count-down with handshake messages gss_token, gss_token, etc., > down to gss_token<1> (these count-down numbers being a purely internal > concept, not appearing on the wire). Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Mar 22 11:13: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 1HUOxd-0000H0-M4; Thu, 22 Mar 2007 11:12:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOxb-0000Gn-Tw for tls@ietf.org; Thu, 22 Mar 2007 11:12:15 -0400 Received: from moutng.kundenserver.de ([212.227.126.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUOx2-0001lW-4x for tls@ietf.org; Thu, 22 Mar 2007 11:12:15 -0400 Received: from [134.147.40.251] (helo=tau.invalid) From tls-bounces@lists.ietf.org Thu Mar 22 11:13: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 1HUOxP-0000Dg-Dn; Thu, 22 Mar 2007 11:12:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOxN-0000D7-Rj for tls@ietf.org; Thu, 22 Mar 2007 11:12:01 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUOwn-0001jV-4t for tls@ietf.org; Thu, 22 Mar 2007 11:12:01 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1HUOwh1USq-0002BA; Thu, 22 Mar 2007 16:11:19 +0100 Received: by tau.invalid (Postfix, from userid 1000) id B109C1B60D; Thu, 22 Mar 2007 16:11:21 +0100 (CET) Date: Thu, 22 Mar 2007 16:11:21 +0100 From: Bodo Moeller To: Stefan Santesson Subject: Re: [TLS] TLS state machine Message-ID: <20070322151121.GA30669@tau.invalid> References: <20070322144814.GA28786@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070322144814.GA28786@tau.invalid> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1+mDdH3q5xAnoA++h8JCia3vJaSfU5t6nPoKHW ma9ZdWjmVc7ptnCogVBzot/TRofJNy7+7eCgaX+lho8aUayoH0 s/0sZQTdvKirVvFHxQSXQ== 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, Mar 22, 2007 at 03:48:14PM +0100, Bodo Moeller wrote: [...] > This particular concern might be cured by requiring any specific > GSS-API mechanism to provide to the TLS layer (an upper bound on) the > number of messages to be exchanged before the GSS-API portion of the > handshake actually starts. Oops, the wording I chose here turns out to be ambiguous. What I meant is: This particular concern might be cured by requiring any specific GSS-API mechanism to provide to the TLS layer, before the GSS-API portion of the handshake actually starts, (an upper bound on) the number of messages to be exchanged. > Then you could have the TLS layer do a > count-down with handshake messages gss_token, gss_token, etc., > down to gss_token<1> (these count-down numbers being a purely internal > concept, not appearing on the wire). Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Mar 22 11:13: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 1HUOxd-0000H0-M4; Thu, 22 Mar 2007 11:12:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOxb-0000Gn-Tw for tls@ietf.org; Thu, 22 Mar 2007 11:12:15 -0400 Received: from moutng.kundenserver.de ([212.227.126.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUOx2-0001lW-4x for tls@ietf.org; Thu, 22 Mar 2007 11:12:15 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1HUOkb0akO-0000YO; Thu, 22 Mar 2007 15:58:49 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 7FAAE1B60A; Thu, 22 Mar 2007 15:48:14 +0100 (CET) Date: Thu, 22 Mar 2007 15:48:14 +0100 From: Bodo Moeller To: Stefan Santesson Subject: Re: [TLS] TLS state machine Message-ID: <20070322144814.GA28786@tau.invalid> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1/ya7yWTIHTfU2JKyMor8YUA6IucEmCppuqRHG HqR7bcU1XqOpz3BUTyIifAT/imKTnQAP7iUN0eeeWc1KC591dn B3rNyVzfrdMbys4B/OJHg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Wed, Mar 21, 2007 at 06:35:59PM +0000, Stefan Santesson wrote: > Considering this being the TLS state machine, the TLS extension > mechanism clearly allows a change of the TLS state machine as it > allows other handshake messages to be inserted in this flow. > > What are the criteria that distinguish a valid change to the TLS > state machine from an invalid (unsuitable) one? > Or is this totally subjective? I guess this generally is pretty much subjective: changes to the standard TLS handshake state machine for specific ciphersuites or extensions presumably would be accepted if there are compelling arguments supporting these changes. Here draft-santesson-tls-gssapi-01.txt has a (potentially curable) problem because it explains what you would be able to do, but not why and when you would want to do this. However, if I understand Eric's criticism correctly, his main complaint concerning the state machine is not that there *are* changes; rather, it is that the changes are quite drastic. The standard TLS handshake state machine has the following simple properties: - There is a finite number of states. - Any given handshake will end (one way or another) after a finite number of handshake messages has been exchanged -- i.e., the state transition diagram does not have any cycles. The standard TLS handshake state machine (as well as extended TLS handshake state machines maintaining similar properties) inherently bounds the number of rounds and the amount of data exchanged in any given handshake. draft-santesson-tls-gssapi-01.txt doesn't do that, unless considered in conjunction with specific GSS-API mechanisms enforcing specific bounds. Even if you are willing to trust that any specific GSS-API mechanism will guarantee a finite handshake, draft-santesson-tls-gssapi-01.txt doesn't guarantee upper bounds. This particular concern might be cured by requiring any specific GSS-API mechanism to provide to the TLS layer (an upper bound on) the number of messages to be exchanged before the GSS-API portion of the handshake actually starts. Then you could have the TLS layer do a count-down with handshake messages gss_token, gss_token, etc., down to gss_token<1> (these count-down numbers being a purely internal concept, not appearing on the wire). Bodo __________________________ by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1HUOkb0akO-0000YO; Thu, 22 Mar 2007 15:58:49 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 7FAAE1B60A; Thu, 22 Mar 2007 15:48:14 +0100 (CET) Date: Thu, 22 Mar 2007 15:48:14 +0100 From: Bodo Moeller To: Stefan Santesson Subject: Re: [TLS] TLS state machine Message-ID: <20070322144814.GA28786@tau.invalid> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1/ya7yWTIHTfU2JKyMor8YUA6IucEmCppuqRHG HqR7bcU1XqOpz3BUTyIifAT/imKTnQAP7iUN0eeeWc1KC591dn B3rNyVzfrdMbys4B/OJHg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Wed, Mar 21, 2007 at 06:35:59PM +0000, Stefan Santesson wrote: > Considering this being the TLS state machine, the TLS extension > mechanism clearly allows a change of the TLS state machine as it > allows other handshake messages to be inserted in this flow. > > What are the criteria that distinguish a valid change to the TLS > state machine from an invalid (unsuitable) one? > Or is this totally subjective? I guess this generally is pretty much subjective: changes to the standard TLS handshake state machine for specific ciphersuites or extensions presumably would be accepted if there are compelling arguments supporting these changes. Here draft-santesson-tls-gssapi-01.txt has a (potentially curable) problem because it explains what you would be able to do, but not why and when you would want to do this. However, if I understand Eric's criticism correctly, his main complaint concerning the state machine is not that there *are* changes; rather, it is that the changes are quite drastic. The standard TLS handshake state machine has the following simple properties: - There is a finite number of states. - Any given handshake will end (one way or another) after a finite number of handshake messages has been exchanged -- i.e., the state transition diagram does not have any cycles. The standard TLS handshake state machine (as well as extended TLS handshake state machines maintaining similar properties) inherently bounds the number of rounds and the amount of data exchanged in any given handshake. draft-santesson-tls-gssapi-01.txt doesn't do that, unless considered in conjunction with specific GSS-API mechanisms enforcing specific bounds. Even if you are willing to trust that any specific GSS-API mechanism will guarantee a finite handshake, draft-santesson-tls-gssapi-01.txt doesn't guarantee upper bounds. This particular concern might be cured by requiring any specific GSS-API mechanism to provide to the TLS layer (an upper bound on) the number of messages to be exchanged before the GSS-API portion of the handshake actually starts. Then you could have the TLS layer do a count-down with handshake messages gss_token, gss_token, etc., down to gss_token<1> (these count-down numbers being a purely internal concept, not appearing on the wire). Bodo _______________________________________________ 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 Mar 22 13:58: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 1HURWv-0003vY-JD; Thu, 22 Mar 2007 13:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURWu-0003tq-Nt for tls@ietf.org; Thu, 22 Mar 2007 13:56:52 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HURTi-0000bQ-Jd for tls@ietf.org; Thu, 22 Mar 2007 13:54:02 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA17004; Thu, 22 Mar 2007 19:47:38 +0200 (MESZ) From: Martin Rex Message-Id: <200703221747.SAA21763@uw1048.wdf.sap.corp> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 To: jaltman@secure-endpoints.com Date: Thu, 22 Mar 2007 18:47:36 +0100 (MET) In-Reply-To: <460291F7.6090804@secure-endpoints.com> from "Jeffrey Altman" at Mar 22, 7 10:25:59 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: e5ba305d0e64821bf3d8bc5d3bb07228 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 Jeffrey Altman wrote: > > Martin Rex wrote: > > Making it easy or encouraging people to configure future Web-Servers > > with TLS_GSSAPI only ciphersuites is equal to dropping > > mandatory to implement ciphersuites and traditional strong interoperability > > of TLS will be lost forever. > The sites that have deployed RFC 2712 do not have certificates today and > they want to force users to authenticate using there existing Kerberos > infrastructure. Forcing the deployment of a certificate in order to > deploy TLS_GSS is not going to alter the behavior of the administrators > who insist that only Kerberos mutual authentication be used. > > Please remember that mandatory to implement does not mean mandatory to > deploy. There is nothing preventing the deployment of a server that > supports both TLS_GSS and certificate based ciphers that are used in > most public settings. Adding complexity to the deployment of TLS_GSS > is not going to alter the deployment policies of the administrators who > use it. Actually, I would appreciate a (new) requirement that a TLS server MUST posess at least a self-signed credential for one of the mandatory-to-implement ciphersuites that include server authentication. Allowing the admin to disable the ciphersuite is OK, but allowing the implementation to run without any credential for at least one of the mandatory-to-implement ciphersuites appears to be a bug in the interoperability concept behind the mandatory to implement ciphersuites. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Mar 22 17:09:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUUV4-0002Hw-IA; Thu, 22 Mar 2007 17:07:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUUV3-0002Ho-DW for tls@ietf.org; Thu, 22 Mar 2007 17:07:09 -0400 Received: from smtpout1471.sc1.he.tucows.com ([64.97.157.171] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUUUy-0001tm-Te for tls@ietf.org; Thu, 22 Mar 2007 17:07:09 -0400 Received: from [192.168.0.2] (24.6.51.98) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 45B8E5A000BBD040 for tls@ietf.org; Thu, 22 Mar 2007 21:07:03 +0000 Message-ID: <4602EFEB.3080308@bolyard.com> Date: Thu, 22 Mar 2007 14:06:51 -0700 From: Nelson B Bolyard Organization: Spam haters R US User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070310 SeaMonkey/1.5a MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00 References: <20070322060158.F34491CC29@delta.rtfm.com> <46022064.70702@secure-endpoints.com> In-Reply-To: <46022064.70702@secure-endpoints.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Jeffrey Altman wrote: > EKR wrote: >> Sure, but as we're seeing in a number of applications, this doesn't >> preclude the use of self-signed certs. > > No it doesn't. However, as I've seen in a number of commercial and open > source products, the authors don't want to go to the trouble of writing > code to generate certificates as part of the install so they install the > same self-signed certificate and private key on every system in the > world. Most users are to naive to know how to replace the certificate, > probably don't know that they should, and assume that because there is a > certificate there that they are secure. One of these commercial products > and its self-signed certificate was in use for many years by a major > Medicare system. Because of the proliferation of self-signed server certs in the markets for certain application protocols, most commercial clients for those protocols now do NO server cert validity checking, to avoid problems with those ubiquitous self-signed server certs. Such is the pernicious power of self-signed server certs. > Self-signed certificates have their place but they should not be used as > a bootstrap method for other authentication technologies. Too many > people make the wrong assumptions just based upon their presence. Hear, hear! > Please do not insist that they be used as part of a TLS-GSS solution. Please don't even suggest that they be used. > Jeffrey Altman /Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 23 08:55: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 1HUjFz-00038W-Rb; Fri, 23 Mar 2007 08:52:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUjFy-00038M-GT for tls@ietf.org; Fri, 23 Mar 2007 08:52:34 -0400 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUjFx-0001HA-2E for tls@ietf.org; Fri, 23 Mar 2007 08:52:34 -0400 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 23 Mar 2007 12:52:31 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Fri, 23 Mar 2007 12:52:31 +0000 From: Stefan Santesson To: "martin.rex@sap.com" Date: Fri, 23 Mar 2007 12:52:29 +0000 Subject: RE: [TLS] Re: Review of draft-santesson-tls-gssapi-00 Thread-Topic: [TLS] Re: Review of draft-santesson-tls-gssapi-00 Thread-Index: AcdsFFfpeKMlrebtQXmWuHUyzjKhcwBNC9QQ Message-ID: References: from "Stefan Santesson" at Mar 21, 7 06:22:10 pm <200703212354.AAA26346@uw1048.wdf.sap.corp> In-Reply-To: <200703212354.AAA26346@uw1048.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 In-line Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Martin Rex [mailto:martin.rex@sap.com] > Sent: den 22 mars 2007 00:55 > To: Stefan Santesson > Cc: tls@ietf.org > Subject: Re: [TLS] Re: Review of draft-santesson-tls-gssapi-00 > > Stefan Santesson wrote: > > > > I disagree that the application need to be altered in the original > proposal. > > > > It all depends on where TLS obtains its policies and parameters. > > If that is supplied by separate configuration or policy DB, then the > > originally proposed handshake can be performed transparent to the > > application. > > With a clean design, you'll have to alter the application. > I think this is where we have the principal disagreement. A clean design fr= om an implementation standpoint allow applications to invoke TLS with no al= terations to the applications. IN particular when the choice of authenticat= ion and encryption method is determined by a separate policy module. Many a= pplications require this simplicity. Its easier to get things right within = TLS implementation then to have applications to get this right. It is also = much easier to upgrade the TLS implementation than all applications using i= t. > A very short-sighted approach might work with some major hacks > in some environments. > > Keep in mind that GSS-API abstraction normally means "authentication > of a communication peer", and there is no requirement that this peer > is anyhow related to user accounts of the local OS. > This would of course only be requested and invoked where it makes sense. I = see no problem with controlling this. > A clean architecture would ultimately allow binary plug-n-play of the > gssapi mechanism with the TLS stack. And since it is not know in > advance what fancy gssapi extensions the mechanism will have, what > the names will look like and wether or how gssapi state could > be persisted, the TLS stack should NOT sit between the gssapi > mechanism and the application, but underneath the gssapi mechanism. > GSS-API state may include alternative names, authorization data > and that information may be entirely independent (or incompatible) > with the native-OS means to represent such data. > To me, the extnesion mechanism provide a precise and straightforward negoti= ation mechanism. This option will not be imposed on anyone that does not ag= ree on using the particular GSS-exchange chosen. > If someone says "In my scenario I could do it transparently", > then he might be thinking with an extremely narrow focus and not > sufficiently general for the architecture of the protocols at hand > (TLS,GSS-API). > > > Another issue: TLS session can be cached and can be "forked". > In fact, it is common practice to "fork" TLS sessions frequently. > > GSS-API security contexts, on the other hand, can not normally > be duplicated. And quite a lot of gssapi mechanism require/enforce > a strictly sequential stream of protected messages (which is how > they provide data replay protection). > Accordingly I would not expect a client and server to agree on using GSS-TL= S unless it is meaningful and appropriate for the session. As I would not e= xpect a server to accept anon-DH if client authentication is required. > I really don't want to see the TLS stack being bothered with > persisting state from the GSS-API authentication beyond > a (flat) peer name. > And I think this problem is important enough to solve. I whish there was an= easier way to do it that works transparent to applications. If there is, I= 'm more than willing to consider it. /Stefan > > -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 23 14:14: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 1HUoEs-0006lY-Gg; Fri, 23 Mar 2007 14:11:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUoEq-0006g8-91 for tls@ietf.org; Fri, 23 Mar 2007 14:11:44 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUoEo-0000ED-Pj for tls@ietf.org; Fri, 23 Mar 2007 14:11:44 -0400 Received: from pc6 (1Cust249.tnt8.lnd4.gbr.da.uu.net [62.188.137.249]) by astro.systems.pipex.net (Postfix) with SMTP id A9BD2E0001EA; Fri, 23 Mar 2007 18:11:28 +0000 (GMT) Message-ID: <000801c76d6d$f457b500$0601a8c0@pc6> From: "tom.petch" To: "Stefan Santesson" , , References: <200703081752.SAA13445@uw1048.wdf.sap.corp><861wjyfnmp.fsf@delta.rtfm.com><86fy8ee7g5.fsf@delta.rtfm.com><33F43BC3-4F76-48B1-9DC9-3B05C951C7BE@checkpoint.com> Subject: Re: [TLS] TLS state machine Date: Fri, 23 Mar 2007 10:56:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.2 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" 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: "Stefan Santesson" To: ; Sent: Wednesday, March 21, 2007 7:35 PM Subject: RE: [TLS] TLS state machine Thank you Pasi, Considering this being the TLS state machine, the TLS extension mechanism clearly allows a change of the TLS state machine as it allows other handshake messages to be inserted in this flow. What are the criteria that distinguish a valid change to the TLS state machine from an invalid (unsuitable) one? Or is this totally subjective? Hang on a bit; no way is what Pasi provided a complete state machine. As EKR has said many times, he regards the number of round trips as a key component and, although this is not exactly obvious in TLS1.2, it is implicitly Client->server client<-server Client->server client<-server and whether or not this is embodied in a state machine is a matter of expression. The key objection to this proposal I hear is of an increase in, perhaps an unbounded increase in, the number of such round trips. Tom Petch Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: den 21 mars 2007 16:07 > To: Stefan Santesson; tls@ietf.org > Subject: RE: [TLS] TLS state machine > > > The state machine is (sort of implicitly) described in these two > figures, copied from RFC 4346: > > ClientHello --------> > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > And the session resumption case: > > ClientHello --------> > ServerHello > [ChangeCipherSpec] > <-------- Finished > [ChangeCipherSpec] > Finished --------> > Application Data <-------> Application Data > > I'm not sure if using a state machine description language would > actually help understanding, but it could look something like this > (server's initial state): > > State: WAITING_FOR_CLIENT_HELLO > Event: ClientHello received > process the client hello > if (didn't work out) > send alert > next state: FAILED > else if (session being resumed) > send ServerHello, ChangeCipherSpec, Finished > next state: WAITING_FOR_CCS > else > send ServerHello [Certificate] [ServerKeyExchange] > [CertificateRequest] ServerHelloDone > next state: WAITING_FOR_CERT_OR_CLIENT_KEY_EXCHANGE > Event: anything else > maybe send alert > go to state FAILED > > (The TLS implementations I've taken a look at actually have code > that resembles this.) > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Stefan Santesson [mailto:stefans@microsoft.com] > > Sent: 21 March, 2007 16:37 > > To: tls@ietf.org > > Subject: [TLS] TLS state machine > > > > We have had lots of discussions around GSS-TLS ending in > > arguments that this would do too many changes to the TLS > > state machine. > > > > It would be a lot easier to hold that discussion > > constructively if the TLS state machine was clearly > > described. A search for the term "state machine" in current > > TLS 1.2 returns empty. I can't find any other text that would > > clearly resemble such description. > > > > Would it be possible to add an annex in TLS 1.2 describing > > the TLS state machine? > > > > It would then be a lot easier to analyze and discuss the > > impact of any changes caused by various usages of the TLS > > extensibility mechanisms. > > > > > > Stefan Santesson > > Senior Program Manager > > Windows Security, Standards _______________________________________________ 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 Tue Mar 27 07:55: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 1HWAE0-000680-7K; Tue, 27 Mar 2007 07:52:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWADy-00067q-KO for tls@ietf.org; Tue, 27 Mar 2007 07:52:26 -0400 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWADl-00025h-4K for tls@ietf.org; Tue, 27 Mar 2007 07:52:26 -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 NAA237816 for ; Tue, 27 Mar 2007 13:50:42 +0100 Message-ID: <46090546.3030507@isima.fr> Date: Tue, 27 Mar 2007 13:51:34 +0200 From: badra User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: tls mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [TLS] DTLS implementation 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 all, I am looking for a stable implementation of DTLS, since OpenSSL does not implement it correctly, could you please let me know if there is other stable ones? Best regards -- 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 Tue Mar 27 08:25: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 1HWAiL-0003SR-Jz; Tue, 27 Mar 2007 08:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWAiJ-0003SE-Nh for tls@ietf.org; Tue, 27 Mar 2007 08:23:47 -0400 Received: from sd-green-bigip-119.dreamhost.com ([208.97.132.119] helo=randymail-a8.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWAiI-0007xB-AK for tls@ietf.org; Tue, 27 Mar 2007 08:23:47 -0400 Received: from delta.rtfm.com (c-71-198-184-110.hsd1.ca.comcast.net [71.198.184.110]) by randymail-a8.g.dreamhost.com (Postfix) with ESMTP id A8214AF564; Tue, 27 Mar 2007 05:23:45 -0700 (PDT) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 2222C1CC22; Tue, 27 Mar 2007 05:22:27 -0700 (PDT) To: badra Subject: Re: [TLS] DTLS implementation In-reply-to: Your message of "Tue, 27 Mar 2007 13:51:34 +0200." <46090546.3030507@isima.fr> X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Tue, 27 Mar 2007 05:22:27 -0700 From: EKR Message-Id: <20070327122227.2222C1CC22@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tls mailing list 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 badra wrote: > I am looking for a stable implementation of DTLS, since OpenSSL does > not implement it correctly, could you please let me know if there is > other stable ones? In the specific case of OpenSSL, I'm aware of some issues and am working with the maintainers to get them fixed. As a general matter, I'd love to hear about other implementations and do some interop on my fixes :) Best, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 30 12:19: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 1HXJmx-0004pO-57; Fri, 30 Mar 2007 12:17:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJmv-0004p7-JT for tls@ietf.org; Fri, 30 Mar 2007 12:17:17 -0400 Received: from smtpauth03.prod.mesa1.secureserver.net ([64.202.165.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HXJmt-0008Aj-PQ for tls@ietf.org; Fri, 30 Mar 2007 12:17:17 -0400 Received: (qmail 21043 invoked from network); 30 Mar 2007 16:17:03 -0000 Received: from unknown (68.54.251.63) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 30 Mar 2007 16:17:02 -0000 From: "Ron Teitelbaum" To: Date: Fri, 30 Mar 2007 12:17:02 -0400 Organization: US Medical Records Specialists Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdy5tmrBtSmR4aRQfCiEZ6233d2oA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [TLS] RC2 examples X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ron@USMedRec.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 Hi All, Does anyone have a play by play listing of bytes through RC2? It would be nice to be able to debug each piece as I go with a concrete example. Thanks for your help! (sorry for the spam on this list, keep up the good work!) Ron Teitelbaum Squeak Cryptography Team Leader _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 30 12:48: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 1HXKGW-0006uR-P8; Fri, 30 Mar 2007 12:47:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKGW-0006uM-CJ for tls@ietf.org; Fri, 30 Mar 2007 12:47:52 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXKGV-0004XO-6B for tls@ietf.org; Fri, 30 Mar 2007 12:47:52 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 01D68D13FA for ; Fri, 30 Mar 2007 12:48:13 -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 rune.sasl.smtp.pobox.com (Postfix) with ESMTP id BD647D13B6 for ; Fri, 30 Mar 2007 12:48:12 -0400 (EDT) Message-ID: <460D3F17.2080109@pobox.com> Date: Fri, 30 Mar 2007 09:47:19 -0700 From: Mike User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] RC2 examples 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: 7aefe408d50e9c7c47615841cb314bed 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 > Does anyone have a play by play listing of bytes through RC2? It would be > nice to be able to debug each piece as I go with a concrete example. I would suggest not supporting RC2 as it is used only in crippled 40-bit EXPORT mode. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 30 12:58: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 1HXKQL-0007nc-Ve; Fri, 30 Mar 2007 12:58:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKQK-0007m2-9v for tls@ietf.org; Fri, 30 Mar 2007 12:58:00 -0400 Received: from yancy.pkiclue.com ([209.172.115.117] helo=yancy.b70.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXKQI-0006Sj-SY for tls@ietf.org; Fri, 30 Mar 2007 12:58:00 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by yancy.b70.net (8.9.3/8.9.3) with ESMTP id JAA24507 for ; Fri, 30 Mar 2007 09:57:50 -0800 Message-ID: <460D4F94.3080909@canola-jones.com> Date: Fri, 30 Mar 2007 09:57:40 -0800 From: Rodney Thayer User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] RC2 examples References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Ron Teitelbaum wrote: > Hi All, > > Does anyone have a play by play listing of bytes through RC2? It would be > nice to be able to debug each piece as I go with a concrete example. > > Thanks for your help! (sorry for the spam on this list, keep up the good > work!) > > Ron Teitelbaum > Squeak Cryptography Team Leader Hasn't RC2 been broken? Wouldn't that suggest that new implementations should not include it unless they have (carefully controlled) backwards compatability requirements? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Mar 30 13:00: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 1HXKRc-00007l-W2; Fri, 30 Mar 2007 12:59:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKRb-00007f-HL for tls@ietf.org; Fri, 30 Mar 2007 12:59:19 -0400 Received: from [64.202.165.35] (helo=smtpauth12.prod.mesa1.secureserver.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HXKRa-0006lt-5J for tls@ietf.org; Fri, 30 Mar 2007 12:59:19 -0400 Received: (qmail 9602 invoked from network); 30 Mar 2007 16:59:17 -0000 Received: from unknown (68.54.251.63) by smtpauth12.prod.mesa1.secureserver.net (64.202.165.35) with ESMTP; 30 Mar 2007 16:59:06 -0000 From: "Ron Teitelbaum" To: "'Mike'" References: <460D3F17.2080109@pobox.com> Subject: RE: [TLS] RC2 examples Date: Fri, 30 Mar 2007 12:59:05 -0400 Organization: US Medical Records Specialists Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <460D3F17.2080109@pobox.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdy6692QmxMbs+5TSSfmBIU/upxEAAACsIw 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 Reply-To: Ron@USMedRec.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 Hi Mike, I'm implementing it so that we can support PKCS files. PKCS5-RC2-128 Is this not necessary? What formats are most CA's returning signed CSR's in? Thanks, Ron > -----Original Message----- > From: Mike [mailto:mike-list@pobox.com] > Sent: Friday, March 30, 2007 12:47 PM > To: tls@ietf.org > Subject: Re: [TLS] RC2 examples > > > Does anyone have a play by play listing of bytes through RC2? It would > be > > nice to be able to debug each piece as I go with a concrete example. > > I would suggest not supporting RC2 as it is used only in crippled > 40-bit EXPORT mode. > > Mike > > _______________________________________________ > 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 Mar 30 18:38: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 1HXPho-0008JB-5f; Fri, 30 Mar 2007 18:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXPhm-0008Ev-5o for tls@ietf.org; Fri, 30 Mar 2007 18:36:23 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXPhk-0007Ji-Vw for tls@ietf.org; Fri, 30 Mar 2007 18:36:22 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 74BD02EF for ; Fri, 30 Mar 2007 18:36:42 -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 3F2633BCCE for ; Fri, 30 Mar 2007 18:36:42 -0400 (EDT) Message-ID: <460D90C3.90200@pobox.com> Date: Fri, 30 Mar 2007 15:35:47 -0700 From: Mike User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] RC2 examples References: <460D3F17.2080109@pobox.com> 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: d17f825e43c9aed4fd65b7edddddec89 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'm implementing it so that we can support PKCS files. PKCS5-RC2-128 > > Is this not necessary? What formats are most CA's returning signed CSR's > in? My response was with a TLS mindset. In TLS, RC2 is used only in 40-bit EXPORT mode, so it is not secure. I don't know the status of 128-bit RC2, although someone else has suggested that it's been broken. Better to use something more modern such as AES 128 or even 256. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Mar 31 06:16: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 1HXabN-0000ny-Td; Sat, 31 Mar 2007 06:14:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXabM-0000no-RB for tls@ietf.org; Sat, 31 Mar 2007 06:14:28 -0400 Received: from moe.its.auckland.ac.nz ([130.216.10.121] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXabK-0001Xj-EX for tls@ietf.org; Sat, 31 Mar 2007 06:14:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 69014480526; Sat, 31 Mar 2007 22:14:22 +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 ablYbqWGe4T8; Sat, 31 Mar 2007 22:14:22 +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 4CFAA4804E8; Sat, 31 Mar 2007 22:14:22 +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 CD2A3128007; Sat, 31 Mar 2007 22:14:21 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HXabN-0006oS-00; Sat, 31 Mar 2007 22:14:29 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Ron@USMedRec.com Subject: RE: [TLS] RC2 examples In-Reply-To: Message-Id: Date: Sat, 31 Mar 2007 22:14:29 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 "Ron Teitelbaum" writes: >I'm implementing it so that we can support PKCS files. PKCS5-RC2-128 > >Is this not necessary? What formats are most CA's returning signed CSR's in? "X.509 certificates" is the usual answer to this question. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Mar 31 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 1HXoOR-0005vA-Jl; Sat, 31 Mar 2007 20:58:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXoOQ-0005v5-K6 for tls@ietf.org; Sat, 31 Mar 2007 20:58:02 -0400 Received: from smtpauth03.prod.mesa1.secureserver.net ([64.202.165.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HXoOH-0006pO-Td for tls@ietf.org; Sat, 31 Mar 2007 20:58:02 -0400 Received: (qmail 24161 invoked from network); 1 Apr 2007 00:57:46 -0000 Received: from unknown (68.54.251.63) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 01 Apr 2007 00:57:46 -0000 From: "Ron Teitelbaum" To: "'pgut001'" References: Subject: RE: [TLS] RC2 examples Date: Sat, 31 Mar 2007 20:57:50 -0400 Organization: US Medical Records Specialists Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdzfVu0V7LAyyR+TFWno5Hs+5Zb7gAej+MQ X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ron@USMedRec.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 That's pretty funny! Yes indeed, and that is what I'm finding. But I'm also finding encrypted .PEM files. Also I'm looking at PCKS-12 exported X509 certs. It appears that part of the file is encrypted by Microsoft using RC2. So if anyone has anything it would really be helpful. A key and the results of an expanded key. A 64bit world and the results of a mix or mash. Anything would be great. I have the algorithm completed but in smalltalk we start indexing at 1 not 0, so I think I have an offset problem somewhere. It's hard to debug blind. Ron > -----Original Message----- > From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] > Sent: Saturday, March 31, 2007 6:14 AM > To: Ron@USMedRec.com > Cc: tls@ietf.org > Subject: RE: [TLS] RC2 examples > > "Ron Teitelbaum" writes: > > >I'm implementing it so that we can support PKCS files. PKCS5-RC2-128 > > > >Is this not necessary? What formats are most CA's returning signed CSR's > in? > > "X.509 certificates" is the usual answer to this question. > > Peter. > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Mar 31 21:12: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 1HXobj-0003X2-LZ; Sat, 31 Mar 2007 21:11:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXobh-0003Wx-Vz for tls@ietf.org; Sat, 31 Mar 2007 21:11:45 -0400 Received: from relay1.mail.uk.clara.net ([80.168.70.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXobb-0001FC-Jy for tls@ietf.org; Sat, 31 Mar 2007 21:11:45 -0400 Received: from [149.254.200.222] (helo=[10.36.177.247]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from ) id 1HXobP-0008FV-RM for tls@ietf.org; Sun, 01 Apr 2007 02:11:34 +0100 Message-ID: <460F06B8.5000607@drh-consultancy.demon.co.uk> Date: Sun, 01 Apr 2007 02:11:20 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] RC2 examples References: In-Reply-To: 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: 1.8 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Ron Teitelbaum wrote: > That's pretty funny! > > Yes indeed, and that is what I'm finding. But I'm also finding encrypted > .PEM files. Also I'm looking at PCKS-12 exported X509 certs. It appears > that part of the file is encrypted by Microsoft using RC2. > > So if anyone has anything it would really be helpful. A key and the results > of an expanded key. A 64bit world and the results of a mix or mash. > Anything would be great. I have the algorithm completed but in smalltalk we > start indexing at 1 not 0, so I think I have an offset problem somewhere. > It's hard to debug blind. > Yes the certificates in PKCS#12 files are commonly encrypted using RC2-40. There are several usable RC2 implementations which you can use to debug yours. One for example is in OpenSSL, see www.openssl.org. Steve. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls