From lars.eggert@nokia.com Fri Oct 9 05:50:53 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6617E3A6A77; Fri, 9 Oct 2009 05:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqa-Yyd-gTpE; Fri, 9 Oct 2009 05:50:52 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id B07043A6A5F; Fri, 9 Oct 2009 05:50:51 -0700 (PDT) Received: from [10.180.41.18] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n99CqPS0056323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Oct 2009 15:52:25 +0300 (EEST) (envelope-from lars.eggert@nokia.com) From: Lars Eggert Content-Type: multipart/signed; boundary=Apple-Mail-60--239855342; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 9 Oct 2009 15:52:15 +0300 Message-Id: <60363DD5-FAF8-4BD5-A74B-11C8A01B448C@nokia.com> To: "tcpm@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Fri, 09 Oct 2009 15:52:26 +0300 (EEST) Cc: "iesg@ietf.org IESG" Subject: [tcpm] whether draft-ietf-tcpm-tcpsecure "updates" RFC793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 12:50:53 -0000 --Apple-Mail-60--239855342 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, since the TCPM WG has asked the IESG to determine whether in our understanding draft-ietf-tcpm-tcpsecure "updates" RFC793, the IESG decided on the telechat yesterday that in our understanding, it does not. However, the IESG also acknowledges that there are different interpretations of what the "updates" relationship between documents actually means. The IESG has taken on a work item to document its understanding of this relationship, either through an IESG Statement or maybe through an RFC. Lars --Apple-Mail-60--239855342 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAwOTEyNTIxNVowIwYJKoZIhvcNAQkEMRYEFAPR1QwbhxOBi/xCG+eQnOQJP+HPMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCmz8vAQqxL7JKrQ3Kg+p0oEM8q5Vuv1+GUZjBodB1lsTh5EX0/q4sK5gyIoQDulY6FkRKO ya08Fyg9EuR0znX96NPldJmz0ZkhKx2uClQ6iJv3Mf0AEmQWSo6xCV9qbs4PWcbTbwK330LarY5E Q9jnU8kdLkMh/auM4PPcFrakvDeGlQhhmNRG0wUaTYSeUktmstETB6J1V11uIfid1nUxt2iXMDoM 144lCkm1iolBLtxlO5qazTf5rpe/4SZugygyWex9V+quY7s3cJs5GmEJKEHgtVSBiyucdQ4bs98J u3k6MX8EuduEXRPbIfCGPFna2GzlWT37eo36Xhjcib31AAAAAAAA --Apple-Mail-60--239855342-- From touch@ISI.EDU Mon Oct 19 07:50:43 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A354F28C1C7 for ; Mon, 19 Oct 2009 07:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8lFxz8ZCdaI for ; Mon, 19 Oct 2009 07:50:43 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id E68113A6928 for ; Mon, 19 Oct 2009 07:50:42 -0700 (PDT) Received: from [172.40.40.57] (rrcs-208-125-251-170.nys.biz.rr.com [208.125.251.170]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n9JEngFV004316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Oct 2009 07:49:43 -0700 (PDT) Message-ID: <4ADC7C85.4050408@isi.edu> Date: Mon, 19 Oct 2009 07:49:41 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tcpm Extensions WG X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE09F4F25E9FA1E58A9ECF125" X-MailScanner-ID: n9JEngFV004316 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] [Fwd: New Version Notification for draft-touch-tcp-ao-nat-00] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:50:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE09F4F25E9FA1E58A9ECF125 Content-Type: multipart/mixed; boundary="------------020802060202020008000509" This is a multi-part message in MIME format. --------------020802060202020008000509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, all, The following provides info on the draft that describes the NAT extensions to TCP-AO. They have been submitted as individual for now, with the intent of incorporating the result into the TCP-AO doc *if* we have time before publication and *if* there is consensus to do so. Otherwise, it can published separately as either PS or experimental, if preferred. Joe --------------020802060202020008000509 Content-Type: message/rfc822; name="New Version Notification for draft-touch-tcp-ao-nat-00.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-touch-tcp-ao-nat-00.eml" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9JEkeWJ005150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Oct 2009 07:46:43 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n9JEkPdP016372 for ; Mon, 19 Oct 2009 07:46:27 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 6B4BE3A68C3; Mon, 19 Oct 2009 07:46:18 -0700 (PDT) From: IETF I-D Submission Tool To: touch@ISI.EDU Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091019144618.6B4BE3A68C3@core3.amsl.com> Date: Mon, 19 Oct 2009 07:46:18 -0700 (PDT) X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean Subject: New Version Notification for draft-touch-tcp-ao-nat-00 X-MailScanner-From: wwwrun@core3.amsl.com A new version of I-D, draft-touch-tcp-ao-nat-00.txt has been successfuly submitted by Joseph Touch and posted to the IETF repository. Filename: draft-touch-tcp-ao-nat Revision: 00 Title: A TCP Authentication Option NAT Extension Creation_date: 2009-10-19 WG ID: Independent Submission Number_of_pages: 5 Abstract: This document describes an extension to the TCP Authentication Option to support its use over connections that pass through network address and/or port translators (NATs/NAPTs). This document describes this extension, and is intended that if desired, would be incorporated into the TCP-AO description currently under development. This document is not intended to remain stand-alone. The IETF Secretariat. --------------020802060202020008000509-- --------------enigE09F4F25E9FA1E58A9ECF125 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrcfIUACgkQE5f5cImnZrtfDgCfSAimDMWaLFIs14mVOMw8VRrW pHAAoLlNMtJMrUOHbBxk4+8aE6jSDei5 =pis1 -----END PGP SIGNATURE----- --------------enigE09F4F25E9FA1E58A9ECF125-- From david.borman@windriver.com Mon Oct 19 10:40:32 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCE83A6951 for ; Mon, 19 Oct 2009 10:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjoAEOvA6txf for ; Mon, 19 Oct 2009 10:40:31 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 7EF493A67EC for ; Mon, 19 Oct 2009 10:40:28 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id n9JHeWd4014666 for ; Mon, 19 Oct 2009 10:40:35 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Oct 2009 10:40:34 -0700 Received: from [172.25.44.7] ([172.25.44.7]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Oct 2009 10:40:33 -0700 From: David Borman Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Mon, 19 Oct 2009 12:40:32 -0500 Message-Id: <5931DAF5-E0C8-49C1-AA5D-8D1E3C7E78A8@windriver.com> To: tcpm Extensions WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 19 Oct 2009 17:40:33.0928 (UTC) FILETIME=[42A35880:01CA50E3] Subject: [tcpm] TCPM not meeting in Hiroshima X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 17:40:32 -0000 Hi, The TCPM WG will not be meeting in Hiroshima, because neither Wes nor I are able to attend. Everyone should continue to work on moving things forward on the mailing list. -David Borman, TCPM co-chair From root@core3.amsl.com Mon Oct 19 12:30:03 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 43F5A3A6894; Mon, 19 Oct 2009 12:30:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019193003.43F5A3A6894@core3.amsl.com> Date: Mon, 19 Oct 2009 12:30:03 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-sack-recovery-entry-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 19:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation Author(s) : I. Jarvinen, M. Kojo Filename : draft-ietf-tcpm-sack-recovery-entry-00.txt Pages : 17 Date : 2009-10-19 This document describes a TCP sender algorithm to trigger loss recovery based on the TCP Selective Acknowledgement (SACK) information gathered on a SACK scoreboard instead of simply counting the number of arriving duplicate acknowledgements (ACKs) in the traditional way. The given algorithm is more robust to ACK losses, ACK reordering, missed duplicate acknowledgements due to delayed acknowledgements, and extra duplicate acknowledgements due to duplicated segments and out-of-window segments. The algorithm allows not only a timely initiation of TCP loss recovery but also reduces false fast retransmits. It has a low implementation cost on top of the SACK scoreboard defined in RFC 3517. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-sack-recovery-entry-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-sack-recovery-entry-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19121533.I-D@ietf.org> --NextPart-- From gregory.ietf@gmail.com Mon Oct 19 19:30:32 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0333A63C9 for ; Mon, 19 Oct 2009 19:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icQxHW-lzgx0 for ; Mon, 19 Oct 2009 19:30:31 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 6D7663A62C1 for ; Mon, 19 Oct 2009 19:30:31 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so790980fgg.13 for ; Mon, 19 Oct 2009 19:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=sM2KDfs+miJkV6KKdbXHnue/L/f3LFa/+vPyJ+DTPwA=; b=xJaX5yoIhqSJ2Uc+hkJQRDeqDP8Teo5roQIM07qxLW224ZMLqD+lHFBAiLcjVc1AAw U9G111j6X0A3YYsZycBTbAsV+EM/V1H6uUAzTNW8lxmfeKxIgJk+A54Ewrf7wpo67dlR uI9kqmaS6uNYjBFftqVzgOLMyCVZvMfhUCKls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=Nw4/nM77v8fHW9ZgJTs1KKMRsgLDKueHSBjM9RT4LDjkrLUtfVqFSFM8fQkXD3L6Q7 14yFY0FI2qD1PvqOkIYbBhO/QjUxYRB8Y4hF2ynLZuIS+v8QcajTbswiZMKsSTZc6AUW Xl4euw9caJuZp1NLfvZeQzYH5h95xlWHScbOw= Received: by 10.86.13.7 with SMTP id 7mr3490978fgm.64.1256005836735; Mon, 19 Oct 2009 19:30:36 -0700 (PDT) Received: from Gregory-T60.gmail.com (nat-service4.juniper.net [66.129.225.151]) by mx.google.com with ESMTPS id l12sm508280fgb.22.2009.10.19.19.30.34 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Oct 2009 19:30:35 -0700 (PDT) Message-ID: <4add20cb.0c58560a.5ec5.ffff8c87@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Oct 2009 19:30:31 -0700 To: David Borman , tcpm Extensions WG From: "Gregory M. Lebovitz" In-Reply-To: <5931DAF5-E0C8-49C1-AA5D-8D1E3C7E78A8@windriver.com> References: <5931DAF5-E0C8-49C1-AA5D-8D1E3C7E78A8@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [tcpm] TCPM not meeting in Hiroshima X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 02:30:32 -0000 May I suggest that we go to WG last call on tcp-auth-opt and tcp-ao-crytpo BEFORE Hiroshima, and then have a Bar-BOF to discuss any issues, tweaks, etc. while in Hiroshima? I think we all want this work to proceed as quickly as possible. Joe and I will be ready within a few days with updated I-D's that are in sync and cover all open/known issues/comments. That will give y'all 3 weeks to review, and send comments to list. Thoughts? Gregory. At 10:40 AM 10/19/2009, David Borman wrote: >Hi, > >The TCPM WG will not be meeting in Hiroshima, because neither Wes nor >I are able to attend. Everyone should continue to work on moving >things forward on the mailing list. > > -David Borman, TCPM co-chair > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From david.borman@windriver.com Mon Oct 19 20:30:50 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0923A685B for ; Mon, 19 Oct 2009 20:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZFbGeiKVMyH for ; Mon, 19 Oct 2009 20:30:49 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 8C3973A67DB for ; Mon, 19 Oct 2009 20:30:49 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id n9K3UtFC016133; Mon, 19 Oct 2009 20:30:55 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Oct 2009 20:30:54 -0700 Received: from [172.25.44.7] ([172.25.44.7]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Oct 2009 20:30:54 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: David Borman In-Reply-To: <4add20cb.0c58560a.5ec5.ffff8c87@mx.google.com> Date: Mon, 19 Oct 2009 22:30:52 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <5931DAF5-E0C8-49C1-AA5D-8D1E3C7E78A8@windriver.com> <4add20cb.0c58560a.5ec5.ffff8c87@mx.google.com> To: "Gregory M. Lebovitz" X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 20 Oct 2009 03:30:54.0588 (UTC) FILETIME=[BAFF23C0:01CA5135] Cc: tcpm Extensions WG Subject: Re: [tcpm] TCPM not meeting in Hiroshima X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 03:30:50 -0000 Yep, that's our goal. If these latest versions cover all known issues, we can start the WG last call as soon as they are available. -David Borman, TCPM co-chair On Oct 19, 2009, at 9:30 PM, Gregory M. Lebovitz wrote: > May I suggest that we go to WG last call on tcp-auth-opt and tcp-ao- > crytpo BEFORE Hiroshima, and then have a Bar-BOF to discuss any > issues, tweaks, etc. while in Hiroshima? I think we all want this > work to proceed as quickly as possible. Joe and I will be ready > within a few days with updated I-D's that are in sync and cover all > open/known issues/comments. That will give y'all 3 weeks to review, > and send comments to list. > > Thoughts? > > Gregory. > > At 10:40 AM 10/19/2009, David Borman wrote: >> Hi, >> >> The TCPM WG will not be meeting in Hiroshima, because neither Wes nor >> I are able to attend. Everyone should continue to work on moving >> things forward on the mailing list. >> >> -David Borman, TCPM co-chair >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From rbonica@juniper.net Tue Oct 20 09:02:20 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370C428C12A for ; Tue, 20 Oct 2009 09:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJTQueb1nzkW for ; Tue, 20 Oct 2009 09:02:19 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 32DD83A696B for ; Tue, 20 Oct 2009 09:02:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSt3fECh6BkzRf2Fdb3pp8VoX8M6KAluj@postini.com; Tue, 20 Oct 2009 09:02:27 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Oct 2009 09:01:40 -0700 Received: from [172.28.134.12] (172.28.134.12) by p-emfe01-wf.jnpr.net (172.28.145.22) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Oct 2009 12:01:39 -0400 Message-ID: <4ADDDEE3.2050706@juniper.net> Date: Tue, 20 Oct 2009 12:01:39 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Gregory M. Lebovitz" References: <5931DAF5-E0C8-49C1-AA5D-8D1E3C7E78A8@windriver.com> <4add20cb.0c58560a.5ec5.ffff8c87@mx.google.com> In-Reply-To: <4add20cb.0c58560a.5ec5.ffff8c87@mx.google.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: tcpm Extensions WG , David Borman Subject: Re: [tcpm] TCPM not meeting in Hiroshima X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 16:02:20 -0000 +1 Gregory M. Lebovitz wrote: > May I suggest that we go to WG last call on tcp-auth-opt and > tcp-ao-crytpo BEFORE Hiroshima, and then have a Bar-BOF to discuss > any issues, tweaks, etc. while in Hiroshima? I think we all want this > work to proceed as quickly as possible. Joe and I will be ready > within a few days with updated I-D's that are in sync and cover all > open/known issues/comments. That will give y'all 3 weeks to review, > and send comments to list. > > Thoughts? > > Gregory. > > At 10:40 AM 10/19/2009, David Borman wrote: >> Hi, >> >> The TCPM WG will not be meeting in Hiroshima, because neither Wes nor >> I are able to attend. Everyone should continue to work on moving >> things forward on the mailing list. >> >> -David Borman, TCPM co-chair >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From lars.eggert@nokia.com Tue Oct 20 10:33:20 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18B5C28C17C for ; Tue, 20 Oct 2009 10:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c28Get5qDhw for ; Tue, 20 Oct 2009 10:33:19 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 10D9328C17A for ; Tue, 20 Oct 2009 10:33:18 -0700 (PDT) Received: from [IPv6:2001:14b8:18f::225:ff:fe45:eccf] ([IPv6:2001:14b8:18f:0:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9KHXGi7027902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Oct 2009 20:33:17 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-84-727401132; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4add20cb.0c58560a.5ec5.ffff8c87@mx.google.com> Date: Tue, 20 Oct 2009 20:33:11 +0300 Message-Id: <6F155E31-6929-43EC-A9B9-4B8B1B96C4C3@nokia.com> References: <5931DAF5-E0C8-49C1-AA5D-8D1E3C7E78A8@windriver.com> <4add20cb.0c58560a.5ec5.ffff8c87@mx.google.com> To: "Gregory M. Lebovitz" X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Tue, 20 Oct 2009 20:33:18 +0300 (EEST) Cc: tcpm Extensions WG , David Borman Subject: Re: [tcpm] TCPM not meeting in Hiroshima X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 17:33:20 -0000 --Apple-Mail-84-727401132 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-10-20, at 5:30, Gregory M. Lebovitz wrote: > May I suggest that we go to WG last call on tcp-auth-opt and > tcp-ao-crytpo BEFORE Hiroshima, and then have a Bar-BOF to discuss > any issues, tweaks, etc. while in Hiroshima? I think we all want this > work to proceed as quickly as possible. Certainly! We've been waiting for a certain someone to update the -ao- crypto draft... :-) > Joe and I will be ready > within a few days with updated I-D's that are in sync and cover all > open/known issues/comments. That will give y'all 3 weeks to review, > and send comments to list. > > Thoughts? Sounds great. Lars > > Gregory. > > At 10:40 AM 10/19/2009, David Borman wrote: >> Hi, >> >> The TCPM WG will not be meeting in Hiroshima, because neither Wes nor >> I are able to attend. Everyone should continue to work on moving >> things forward on the mailing list. >> >> -David Borman, TCPM co-chair >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-84-727401132 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyMDE3MzMxMlowIwYJKoZIhvcNAQkEMRYEFH0WMlryUt49XxKKb1nMCg76H2xqMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCYWFaRTeW4BpPwPiItyTlFlWl5gZ9IXBjvoiGsFHSWJ/Es1BKNkeCmAn/CiOnlfU+kuy6n s1PYS12mxENfIB/A53u6lkDKiGWPDQlbR+CVVGkUm6mEfal98rpiYQ3g2V0qBJBAcB3AhtjLXjZK Y9NKyUr5dXWlc5q9hnppoXcl0b/QbALnYiGl81DS1N9Bgv4mxSNHnJ0MTl6wFhIixVuq+E89SpGL obzEkuhzQRZoQbAWrtAx1ZMDhe06SKI1QpI1xuw3JnzWsQClQgxYJ0aZN/4G9EY1xX7R8sW/dQ7Z ke/MHEciaL7Hc6QJfo9VH6VdobwqjdhZeCEOFq51h6GSAAAAAAAA --Apple-Mail-84-727401132-- From alexander.zimmermann@nets.rwth-aachen.de Wed Oct 21 03:22:43 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9123A695C for ; Wed, 21 Oct 2009 03:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5aDtdfwBeJb for ; Wed, 21 Oct 2009 03:22:42 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 9151C3A68C4 for ; Wed, 21 Oct 2009 03:22:42 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KRV00EEQ0U11V10@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 21 Oct 2009 12:22:49 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.44,596,1249250400"; d="scan'208";a="30572219" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 21 Oct 2009 12:22:50 +0200 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KRV00EUV0U1MG70@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 21 Oct 2009 12:22:49 +0200 (CEST) From: Alexander Zimmermann Date: Wed, 21 Oct 2009 12:22:50 +0200 Message-id: To: "tcpm@ietf.org WG Extensions" X-Mailer: Apple Mail (2.1076) Subject: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry update RFC 3717 (SACK-TCP) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 10:22:43 -0000 Hi folks, based on the fact that the draft "draft-ietf-tcpm-sack-recovery-entry" is adopted as WG item now and intended to be a "standards track" document, I would like to start a poll/discussion whether the draft should update RFC 3517 or not? Moreover, should we produce a separate document or an update of RFC 3517? a) separate document, do not update RFC 3517 b) separate document, update RFC 3517 c) RFC3517bis, obsolete RFC 3517 // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From lars.eggert@nokia.com Mon Oct 26 04:21:17 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD6C28C1FC for ; Mon, 26 Oct 2009 04:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiulgBZ6xfay for ; Mon, 26 Oct 2009 04:21:17 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id F2A2028C16F for ; Mon, 26 Oct 2009 04:21:16 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9QBLNZZ082492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 26 Oct 2009 13:21:23 +0200 (EET) (envelope-from lars.eggert@nokia.com) From: Lars Eggert Content-Type: multipart/signed; boundary=Apple-Mail-18--923991185; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 26 Oct 2009 13:21:22 +0200 References: <4AE58173.20502@ripe.net> To: tcpm Extensions WG Message-Id: <59FA5994-22EB-4D81-A88A-EF7551B5CAF2@nokia.com> Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Mon, 26 Oct 2009 13:21:23 +0200 (EET) Subject: [tcpm] Fwd: [ippm] Draft Agenda for IPPM @ IETF76. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 11:21:18 -0000 --Apple-Mail-18--923991185 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes TCP folks may wish to attend IPPM to participate in the discussion on this proposed work item there. Begin forwarded message: > 7. TCP Throughput Testing (Barry Constantine, 20') > http://www.ietf.org/id/draft-constantine-ippm-tcp-throughput-tm-00.txt --Apple-Mail-18--923991185 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyNjExMjEyM1owIwYJKoZIhvcNAQkEMRYEFARgIN3voWJJuwaD0q7PBDrGZ5MoMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDcZgiLoSHEgGlK3+73Em0svYJjBFjit2WCcQtBZLQMeQIcSHJLN0O9NRlGXnDS0Qt512BH +BYsk0zJ59YiHphSJMmbdkMkcnzrwjxed8ujU3MtacdtmWd5Z2niAnWsRya0hYC90ySN9cupCbvc JVE0NwFeRVGLdK9xdcN7TI9Nsd7SC6gBjTG5eNfBJcxOujiOlcqC26yZtIg4IOlkvmo+qm6vSegR aKtqBj9GwjAIKBMZI0lDGPPPil+fa8dodyw+sgdDXJBsoYFNUj4SIXLCmpTgsz3wsIV9hKMLFzNz wa/aToYSkhnB0gjbkCjPqqmcQPauOhmRpYUzmF8BGo05AAAAAAAA --Apple-Mail-18--923991185-- From root@core3.amsl.com Mon Oct 26 14:30:02 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1A41828C183; Mon, 26 Oct 2009 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026213002.1A41828C183@core3.amsl.com> Date: Mon, 26 Oct 2009 14:30:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : The TCP Authentication Option Author(s) : J. Touch, et al. Filename : draft-ietf-tcpm-tcp-auth-opt-06.txt Pages : 46 Date : 2009-10-26 This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either static master key tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses its own option identifier, even though used mutually exclusive of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is fully compatible with the requirements for the replacement of TCP MD5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-auth-opt-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26142405.I-D@ietf.org> --NextPart-- From touch@ISI.EDU Mon Oct 26 15:13:53 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32EF428C301; Mon, 26 Oct 2009 15:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQO+a0DN7pFp; Mon, 26 Oct 2009 15:13:52 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 8373928C19B; Mon, 26 Oct 2009 15:13:52 -0700 (PDT) Received: from [128.9.176.52] (c1-vpn12.isi.edu [128.9.176.52]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n9QMDGMI029610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 15:13:18 -0700 (PDT) Message-ID: <4AE61EFC.3030907@isi.edu> Date: Mon, 26 Oct 2009 15:13:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Internet-Drafts@ietf.org References: <20091026213002.1A41828C183@core3.amsl.com> In-Reply-To: <20091026213002.1A41828C183@core3.amsl.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: n9QMDGMI029610 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, i-d-announce@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 22:13:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, Please ignore this version; we found a glitch and are resubmitting as 07. Joe Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > > Title : The TCP Authentication Option > Author(s) : J. Touch, et al. > Filename : draft-ietf-tcpm-tcp-auth-opt-06.txt > Pages : 46 > Date : 2009-10-26 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrmHvwACgkQE5f5cImnZrsEZwCgjgRg6cbvdMCqp68YN1djGwNG fXMAniXn02i18YHnr9Wqo2vzOicfMhu3 =uJHn -----END PGP SIGNATURE----- From root@core3.amsl.com Mon Oct 26 15:15:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EA71428C323; Mon, 26 Oct 2009 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026221501.EA71428C323@core3.amsl.com> Date: Mon, 26 Oct 2009 15:15:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 22:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : The TCP Authentication Option Author(s) : J. Touch, et al. Filename : draft-ietf-tcpm-tcp-auth-opt-07.txt Pages : 46 Date : 2009-10-26 This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either static master key tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses its own option identifier, even though used mutually exclusive of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is fully compatible with the requirements for the replacement of TCP MD5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-auth-opt-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26151441.I-D@ietf.org> --NextPart-- From andrew.knutsen@bluecoat.com Mon Oct 26 19:01:00 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D03D3A68C6 for ; Mon, 26 Oct 2009 19:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az-M-Q75jVeE for ; Mon, 26 Oct 2009 19:00:59 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id BEDB73A6890 for ; Mon, 26 Oct 2009 19:00:59 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n9R21D5R000493 for ; Mon, 26 Oct 2009 19:01:13 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 19:01:08 -0700 Message-ID: <4AE65463.6020506@bluecoat.com> Date: Mon, 26 Oct 2009 19:01:07 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2009 02:01:08.0198 (UTC) FILETIME=[59598060:01CA56A9] Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , Wei Jen Yeh Subject: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 02:01:00 -0000 A new version of the Transparent Middlebox Discovery option draft is available at . The following changes have been made: - The security section has been updated. - An API section has been added. - Simultaneous open is addressed. - The "device type" field has been renamed "device capability", since a single device may respond to several kinds of discovery requests. - Miscellaneous cleanup and clarifications. Several changes were not made: - Specific uses of the option, such as discovery for management purposes, are not addressed. This information belongs in the specs for the individual device capabilities. - This does need to be a TCP option, since it must follow the same path as the TCP connection handshake. This is already addressed in the draft. - Performance is a requirement for this option. If an extra roundtrip is required, the option will not be used. This is also already addressed in the draft. In addition, we made a couple more changes which I wasn't able to post before the pre-meeting deadline. They include: - Options with length < 4 are addressed. The following text is included: Options with length less than 4 MUST be ignored. - The issue of limited option space is addressed. The following text is included: There may be situations where other options are required in the SYN packet which do not leave enough room for all of the target data necessary for the desired device capability to be advertised. In these cases, a shorter alternate device capability may be defined which signals the request to further negotiate the capability after the handshake completes. This will impact performance by introducing an extra round-trip during connection set-up, but this may be the only way to perform the negotiation within the limited TCP option space available. Unfortunately, none of the authors will be attending Hiroshima. Andrew From touch@ISI.EDU Mon Oct 26 22:44:09 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1C93A68F1 for ; Mon, 26 Oct 2009 22:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7h1ln5RPAXj for ; Mon, 26 Oct 2009 22:44:07 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DCA7C3A68F0 for ; Mon, 26 Oct 2009 22:44:06 -0700 (PDT) Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n9R5hcn3005313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 22:43:40 -0700 (PDT) Message-ID: <4AE6888A.5080205@isi.edu> Date: Mon, 26 Oct 2009 22:43:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andrew Knutsen References: <4AE65463.6020506@bluecoat.com> In-Reply-To: <4AE65463.6020506@bluecoat.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 05:44:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Knutsen wrote: > > A new version of the Transparent Middlebox Discovery option draft is > available at > . > > The following changes have been made: ... > - Simultaneous open is addressed. Simply stating that simultaneous open isn't supported is insufficient. The document needs to explain what happens when a SYN is received with the option when in the SYN-SENT state - i.e., what happens in response to the SYN received, and what happens if the other end responds to the option in the SYN that has been sent. ... > In addition, we made a couple more changes which I wasn't able to post > before the > pre-meeting deadline. They include: > > - Options with length < 4 are addressed. The following text is included: > > Options with length less than 4 MUST be ignored. > > - The issue of limited option space is addressed. The following text is > included: > > There may be situations where other options are required in the SYN > packet which do not leave enough room for all of the target data > necessary for the desired device capability to be advertised. In > these cases, a shorter alternate device capability may be defined > which signals the request to further negotiate the capability after > the handshake completes. This will impact performance by introducing > an extra round-trip during connection set-up, but this may be the > only way to perform the negotiation within the limited TCP option > space available. FWIW, the text in the security considerations needs to take space into account as well, e.g., when asserting that this option can be protected with either TCP MD5 (18 bytes total) or TCP-AO (16 bytes total under both MACs defined in ao-crypto). Given the current ubiquity of the following: o SACK permitted (2 bytes) [RFC2018][RFC3517] o Timestamps (10 bytes) [RFC1323] o Window scale (3 bytes) [RFC1323] The result is 9 bytes remaining with TCP-AO, and 7 with TCP-MD5. That means this option basically has at best trivial target data (at most 3 bytes); if the P-bit is set, there is no room for target data at all. It would be useful to address whether this option is expected to be useful with such little (or no) target data - i.e., is this the typical case, or a useful case? If not, then it would not be appropriate to claim that protection from either of the TCP mechanisms is expected. One additional question - is this option really meaningful only when the SYN bit is set? What happens if you receive it in the SYN-ACK - you won't be able to send a response back in the ACK (i.e., the last step of the three-way handshake). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrmiIkACgkQE5f5cImnZrsa5ACeI+aR+NmHlb0saRdLUHMNeFC7 x3AAn3QXja7BySQXpph7Yna6boyGBuPx =Ku/V -----END PGP SIGNATURE----- From gregory.ietf@gmail.com Mon Oct 26 19:17:41 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6823A68B8 for ; Mon, 26 Oct 2009 19:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DFcjNyUbclA for ; Mon, 26 Oct 2009 19:17:36 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id CDE4D3A6824 for ; Mon, 26 Oct 2009 19:17:35 -0700 (PDT) Received: by pzk42 with SMTP id 42so8992839pzk.31 for ; Mon, 26 Oct 2009 19:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=caj9sCQZ16YVGQlg4gerMYEiVN+nijcNle9amAuxTh8=; b=SI8rn8xp+unSYrJz3TIIykhCCm3cRXDYPap8KQRHINABVT9sZBaS8tOCi3sBltO55+ Irbms9fWWrLhCmWy+ezULBD7QZei/0CMvntNf6JD8ccrEbRuD7RX9vxwG5Aeucy9Tj8U U9NbZSREP5yBfU2s/quYEzNNMSBk29h1ZNoLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=SxO6zse/QI/ozPY88kjpbMenkSRglr4TdBk7aovJEo0ESDyHqoUESyAgidT9V4HbTt ySuRKtl2IX0RKvpl5Dx65WjLyDPl9Z+PJ3QLFtYj4fLcTOXcBUeHg0820NjLod2FLi0s 68OXnAYmqnM89cd+UHOIeeHuel2/WehrNCkUU= Received: by 10.114.236.22 with SMTP id j22mr7490941wah.217.1256609866126; Mon, 26 Oct 2009 19:17:46 -0700 (PDT) Received: from Gregory-T60.gmail.com (natint3.juniper.net [66.129.224.36]) by mx.google.com with ESMTPS id 20sm516840pzk.1.2009.10.26.19.17.43 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Oct 2009 19:17:44 -0700 (PDT) Message-ID: <4ae65848.9413f30a.6b67.3bf8@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Oct 2009 19:17:39 -0700 To: tcpm@ietf.org From: "Gregory M. Lebovitz" In-Reply-To: <7.1.0.9.2.20091026190557.04ff0ca0@gmail.com> References: <7.1.0.9.2.20091026190557.04ff0ca0@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_37082250==.ALT" X-Mailman-Approved-At: Tue, 27 Oct 2009 06:27:45 -0700 Subject: [tcpm] draft-ietf-tcpm-tcp-ao-crypto-01, ready for WG LC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 02:17:41 -0000 --=====================_37082250==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hey all, Below pls find pasted the latest version of draft-ietf-tcpm-tcp-ao-crypto-01 This one should be ready for WG LC. I'll let the WG Chairs make that call. It did not include a change log, but here are the changes: - simplified title of document - Touch - copy edits for read-ability throughout - Touch - switched "Derived_Key" back to "Traffic_Key" in order to sync with -AO spec. - added the two IANA values SHA1 and AES128 to IANA section I missed the cutoff for I-D submission, but have asked Lars (AD) to intervene. Hopefully he can get it published to the repository with a manual push. Gregory. At 07:12 PM 10/26/2009, you wrote: >Attached are the .txt and .xml for the version of >draft-ietf-tcpm-tcp-ao-crypto-01 document, which should be ready for >WG Last Call. It contains all the latest feedback from reviews by >Touch and EKR. I missed the I-D deadline by 2 hours... ughh. The >text of the draft is pasted below, for convenience. > >Lars, can you push this through the I-D editor queue for us?? > >Gregory. >= = = = BEGIN PASTED TEXT; view in fixed width font = = = = > > > >TCPM G. Lebovitz >Internet-Draft Juniper >Intended status: Standards Track E. Rescorla >Expires: April 29, 2010 RTFM > October 26, 2009 > > > Cryptographic Algorithms for TCP's Authentication Option, TCP-AO > draft-ietf-tcpm-tcp-ao-crypto-01 > >Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. This document may contain material > from IETF Documents or IETF Contributions published or made publicly > available before November 10, 2008. The person(s) controlling the > copyright in some of this material may not have granted the IETF > Trust the right to allow modifications of such material outside the > IETF Standards Process. Without obtaining an adequate license from > the person(s) controlling the copyright in such materials, this > document may not be modified outside the IETF Standards Process, and > derivative works of it may not be created outside the IETF Standards > Process, except to format it for publication as an RFC or to > translate it into languages other than English. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on April 29, 2010. > >Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 1] > >Internet-Draft Crypto for TCP-AO October 2009 > > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents in effect on the date of > publication of this document (http://trustee.ietf.org/license-info). > Please review these documents carefully, as they describe your rights > and restrictions with respect to this document. > >Abstract > > The TCP Authentication Option, TCP-AO, relies on security algorithms > to provide authentication between two end-points. There are many > such algorithms available, and two TCP-AO systems cannot interoperate > unless they are using the same algorithm(s). This document specifies > the algorithms and attributes that can be used in TCP-AO's current > manual keying mechanism. > > >Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 > 2.2. Algorithm Requirements . . . . . . . . . . . . . . . . . . 3 > 2.3. Requirements for Future MAC Algorithms . . . . . . . . . . 4 > 3. Algorithms Specified . . . . . . . . . . . . . . . . . . . . . 4 > 3.1. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 5 > 3.1.1. Concrete KDFs . . . . . . . . . . . . . . . . . . . . 6 > 3.2. MAC Algorithms . . . . . . . . . . . . . . . . . . . . . . 10 > 3.2.1. The Use of HMAC-SHA-1-96 . . . . . . . . . . . . . . . 11 > 3.2.2. The Use of AES-128-CMAC-96 . . . . . . . . . . . . . . 11 > 4. Change History (RFC Editor: Delete before publishing) . . . . 12 > 5. Needs Work in Next Draft (RFC Editor: Delete Before > Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 14 > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 > 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 > 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 > > > > > > > > > > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 2] > >Internet-Draft Crypto for TCP-AO October 2009 > > >1. Introduction > > This document is a companion to TCP-AO [TCP-AO] > [I-D.ietf-tcpm-tcp-auth-opt]. Like most modern security protocols, > TCP-AO allows users to chose which cryptographic algorithm(s) they > want to use to meet their security needs. > > TCP-AO provides cryptographic authentication and message integrity > verification between to end-points. In order to accomplish this > function, message authentication codes (MACs) are used, which then > rely on shared keys. There are various ways to create MACs. The use > of hashed-based MACs (HMAC) in Internet protocols is defined in > [RFC2104]. The use of cipher-based MACs (CMAC) in Internet protocols > is defined in [RFC4493]. > > This RFC defines the general requirements for MACs used in TCP-AO, > both for currently specified MACs and for any future specified MACs. > It then specifies two MAC algorithms required in all TCP-AO > implementations. It also specifies two key derivations functions > (KDFs) used to create the traffic keys used by the MACs. These KDFs > are also required by all TCP-AO implementations. > > >2. Requirements > >2.1. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > When used in lower case, these words convey their typical use in > common language, and are not to be interpreted as described in > [RFC2119]. > >2.2. Algorithm Requirements > > This is the initial specification of required cryptography for > TCP-AO, and indicates two MAC algorithms and two KDFs. All four > components MUST be implemented in order for the implementation to be > fully compliant with this RFC. > > The following table indicates the required MAC algorithms and KDFs > for TCP-AO: > > > > > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 3] > >Internet-Draft Crypto for TCP-AO October 2009 > > > Requirement Authentication Algorithm > ------------ ------------------------ > MUST HMAC-SHA-1-96 [RFC2404] > MUST AES-128-CMAC-96 [RFC4493] > > Requirement Key Derivation Function (KDF) > ------------- ------------------------ > MUST KDF_HMAC_SHA1 > MUST KDF_AES_128_CMAC > > NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED: > > Two MAC algorithms and two corresponding KDFs are mandated as a > result of discussion in the TCPM WG, and in consultation with the > Security Area Directors. SHA-1 was selected because it is widely > deployed and currently has sufficient strength and reasonable > computational cost, so it is a "MUST" for TCP-AO today. The security > strength of SHA-1 HMACs should be sufficient for the foreseeable > future, especially given that the tags are truncated to 96 bits. > > Recently exposed vulnerabilities in other MACs (e.g., MD5 or HMAC > MD5) aren't practical on SHA-1, but these types of analyses are > mounting and could potentially pose a concern for HMAC forgery if > they were significantly improved, over time. The security issues > driving the migration from SHA-1 to SHA-256 for digital signatures > [HMAC-ATTACK] do not immediately render SHA-1 weak for this > application of SHA-1 in HMAC mode. > > AES-128 CMAC is considered to be a stronger algorithm than SHA-1, but > may not yet have very wide implementation. AES-128 CMAC is also a > "MUST" to implement, in order to drive vendors toward its use, and to > allow for another MAC option, if SHA-1 were to be compromised. > >2.3. Requirements for Future MAC Algorithms > > TCP-AO is intended to support cryptographic agility. As a result, > this document includes recommendations in various places for future > MAC and KDF algorithms when used for TCP-AO. For future MAC > algorithms specifically, they SHOULD protect at least 2**48 messages > with a collision probability of less than one in 10**9. > > [Reviewers: Are there any other requirements we want/need to place in > here? RFC EDITOR: Please delete this note before publishing as RFC] > > >3. Algorithms Specified > > TCP-AO requires two classes of cryptographic algorithms used on a > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 4] > >Internet-Draft Crypto for TCP-AO October 2009 > > > particular connection, and refers to this document to define them > both: > > > (1) Key Derivation Functions (KDFs) which name a pseudorandom > function (PRF) and use a Master_Key and some connection- > specific input with that PRF to produce Traffic_Keys, the > keys suitable for authenticating and integrity checking > individual TCP segments, as described in TCP-AO. > (2) Message Authentication Code (MAC) algorithms which take a > key and a message and produce an authentication tag which > can be used to verify the integrity and authenticity of > those messages. > > In TCP-AO, these algorithms are always used in pairs. Each MAC > algorithm MUST specify the KDF to be used with that MAC algorithm. > However, a KDF MAY be used with more than one MAC algorithm. > >3.1. Key Derivation Functions (KDFs) > > TCP-AO's Traffic_Keys are derived using KDFs. The KDFs used in TCP- > AO's current manual keying have the following interface: > > Traffic_Key = KDF_algo(Master_Key, Context, Output_Length) > > where: > > > - KDF_algo: the specific pseudorandom function (PRF) that is > the basic building block used in constructing the > given Traffic_Key. > > - Master_Key: In TCP-AO's manual key mode, this is a key shared > by both peers, entered via some interface to their > respective configurations. The Master_Key is used > as the seed for the KDF. We assume that this is a > human-readable pre-shared key (PSK), thus we assume > it is of variable length. Master_Keys SHOULD be > random, but might not be (e.g., badly chosen by the > user). > > - Context : A binary string containing information related to > the specific connection for this derived keying > material. TCP-AO specifies the content of the > Context, which includes things like the TCP segment > prepended by the TCP pseudoheader and TCP header > options, as defined in > [I-D.ietf-tcpm-tcp-auth-opt], Section 7.2] > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 5] > >Internet-Draft Crypto for TCP-AO October 2009 > > > > - Output_Length: The length in bits of the key that the KDF will > produce. This length must be the size required for > the MAC algorithm that will use the PRF result as a > seed. > > When invoked, a KDF generates a string of length Output_Length bits > based on Master_Key and context value. This result may then be used > as a cryptographic key for any algorithm which takes an Output_Length > length key. A KDF MAY specify a maximum Output_Length parameter. > >3.1.1. Concrete KDFs > > This document defines two KDF algorithms, each paired with a > corresponding PRF algorithm as explained below: > > > * KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2404] > * KDF_AES_128_CMAC based on AES-CMAC-PRF-128 [RFC4615] > > > Each > > Both of these KDFs are based on the iteration mode KDFs specified in > [NIST-SP800-108]. This means that they use an underlying > pseudorandom function (PRF) with a fixed-length output lengths, 128 > bits in the case of the AES-CMAC, and 160 bits in the case of HMAC- > SHA1. The KDF generates an arbitrary number of output bits by > operating the PRF in a "counter mode", where each invocation of the > PRF uses a different input block differentiated by a block counter. > > Each input block is constructed as follows: > > ( i || Label || Context || Output_Length) > > Where > > - "||": For any X || Y, "||" represents a concatonation > operation of the binary strings X and Y. > > - i: A counter, a binary string that is an input to each > iteration of the PRF in counter mode. The number of > iterations will depend on the specific size of the > Output_Length desired for a given MAC. > > > > > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 6] > >Internet-Draft Crypto for TCP-AO October 2009 > > > > - Label: A binary string that clearly identifies the purpose > of this KDF's derived keying material. For TCP-AO we > use the ASCII string "TCP-AO", where the last > character is the capital letter "O", not to be > confused with a zero. While this may seem like > overkill in this specification since TCP-AO only > describes one call to the KDF, it is included in > order to comply with FIPS 140 certifications. > > - Context : The context argument provided to the KDF interface, > as described above in Section 3.1 . > > - Output_Length: The length in bits of the key that the KDF will > produce. This length must be the size required for > the MAC algorithm that will use the PRF result as a > seed. > > The ouput of mutiple PRF invocations is simply concatenated. For the > Traffic_Key, values of multiple PRF invocations are concatenated and > truncated as needed to create a Traffic_Key of the desired length. > For instance, if one were using KDF_HMAC_SHA1, which uses a 160-bit > internal PRF to generate 320 bits of data, one would execute the PRF > twice, once with i=0 and once with i=1. The result would be the > entire output of the first invocation concatenated with the second > invocation. E.g., > > Traffic_Key = > KDF_algo(Master_Key, 0 || Label || Context || Output_length) || > KDF_algo(Master_Key, 1 || Label || Context || Output_length) > > If the number of bits required is not an even multiple of the output > size of the PRF, then the output of the final invocation of the PRF > is truncated as necessary. > >3.1.1.1. KDF_HMAC_SHA1 > > For KDF_HMAC_SHA1: > > - PRF: HMAC-SHA1 [RFC2404]. > > - Use: HMAC-SHA1(Key, Input). > > - Key: Master_Key, configured by user, and passed to the KDF. > > > > > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 7] > >Internet-Draft Crypto for TCP-AO October 2009 > > > > - Input: ( i || Label || Context || Output_Length) > > - Output_Length: 160 bits. > > - Result: Traffic_Key, used in the MAC function by TCP-AO. > >3.1.1.2. KDF_AES_128_CMAC > > For KDF_AES_128_CMAC: > > - PRF: AES-CMAC-PRF-128 [RFC4615]. > > - Use: AES-CMAC(Key, Input). > > - Key: Traffic_Master_Key (see below) > > - Input: ( i || Label || Context || Output_Length) > > - Output_Length: 128 bits. > > - Result: Traffic_Key, used in the MAC function by TCP-AO > > The Master_Key in TCP-AO's current manual keying mechanism is a > shared secret, entered by an administrator. It is passed via an out- > of-band mechanism between two devices, and often between two > organizations. The shared secret does not have to be 16 octets, and > the length may vary. However, AES_128_CMAC requires a key of exactly > 16 octets (128 bits) in length. We could mandate that > implementations force administrators to input Master_Keys of exactly > 128 bit length when using AES_128_CMAC, and with sufficient > randomness, but this places undue burden on the implementors and > deployers. This specification RECOMMENDS that deployers use a > randomly generated 128-bit string as the Master_Key, but acknowledges > that deployers may not. > > To handle variable length Master_Keys we use the same mechanism as > described in [RFC4615], Sect 3. First we use AES_128_CMAC with a > fixed key of all zeros as a "randomness extractor", while using the > shared secret Master_Key, MK, as the message input, to produce a 128 > bit key Derived_Master_Key (K). Second, we use the result as a key, > and run AES-128_CMAC again, this time using the result K as the Key, > and the true input block as the Input to yield the Traffic_Key (TK) > used in the MAC over the message. The description follows: > > > > > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 8] > >Internet-Draft Crypto for TCP-AO October 2009 > > > >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > + KDF-AES-128-CMAC + > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > + + > + Input : MK (Master_Key, the variable-length shared secret) + > + : I (Input, i.e., the input data of the PRF) + > + : MKlen (length of MK in octets) + > + : len (length of M in octets) + > + Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable)+ > + + > +-------------------------------------------------------------------+ > + Variable: K (128-bit key for AES-CMAC) + > + + > + Step 1. If MKlen is equal to 16 + > + Step 1a. then + > + K := MK; + > + Step 1b. else + > + K := AES-CMAC(0^128, MK, MKlen); + > + Step 2. TK := AES-CMAC(K, I, len); + > + return TK; + > + + > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > Figure 1 > > In step 1, the 128-bit key, K, for AES-CMAC is derived as follows: > > o If the Master_Key, MK, provided by the administrator is exactly 128 > bits, then we use it as-is. > > o If it is longer or shorter than 128 bits, then we derive the key K > by applying the AES-CMAC algorithm using the 128-bit all-zero string > as the key and MK as the input message. This step is described in > step 1b. > > In step 2, we apply the AES-CMAC algorithm again, this time using K > as the key and I as the input message. > > The output of this algorithm returns TK, the Traffic_Key, which is > 128 bits suitable for use in the MAC function on each TCP segment of > the connection. > >3.1.1.3. Tips for User Interfaces regarding KDFs > > This section provides suggested representations for the KDFs in > implementation user interfaces. Following these guidelines across > common implementations will make interoperability easier and simpler > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 9] > >Internet-Draft Crypto for TCP-AO October 2009 > > > for deployers. > > UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply "SHA1". > > UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply > "AES128". > > The initial IANA registry values will reflect these two entries. > > UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO > settings. KDF_HMAC_SHA1 is preferred at this time because it has > wide support, being present in most implementations in the > marketplace. > >3.2. MAC Algorithms > > Each MAC_algo defined for TCP-AO has three fixed elements as part of > its definition: > > - KDF_Algo: Name of the TCP-AO KDF algorithm used to generate the > Traffic_Key > - Key_Length: Length in bits required for the Traffic_Key used in > this MAC > - Output: The final length of the bits used in the TCP-AO MAC > field. This value may be a truncation of the MAC > function's original output length. > > MACs computed for TCP-AO have the following interface: > > MAC = MAC_algo(Traffic_Key, Message) > > where: > > > - MAC_algo: MAC Algorithm used > - Traffic_Key: Variable; the result of KDF. > - Message The message to be authenticated, as specified in > [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. > > This document specifies two MAC algorithm options for generating the > MAC as used by TCP-AO: > > > * HMAC-SHA-1-96 based on [RFC2404] > > > > > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 10] > >Internet-Draft Crypto for TCP-AO October 2009 > > > > * AES-128-CMAC-96 based on [RFC4493] > > Both provide a high level of security and efficiency. The AES-128- > CMAC-96 is potentially more efficient, particularly in hardware, but > HMAC-SHA-1-96 is more widely used in Internet protocols and in most > cases could be supported with little or no additional code in today's > deployed software and devices. > > An important aspect to note about these algorithms' definitions for > use in TCP-AO is the fact that the MAC outputs are truncated to 96 > bits. AES-128-CMAC-96 produces a 128 bit MAC, and HMAC SHA-1 > produces a 160 bit result. The MAC output are then truncated to 96 > bits to provide a reasonable tradeoff between security and message > size, for fitting into the TCP-AO header. > >3.2.1. The Use of HMAC-SHA-1-96 > > By definition, HMAC [RFC2104] requires a cryptographic hash function. > SHA1 will be that has function used for authenticating and providing > integrity validation on TCP segments with HMAC. > > The three fixed elements for HMAC-SHA-1-96 are: > > - KDF_Algo: KDF_HMAC_SHA1. > - Key_Length: 160 bits. > - Output: 96 bits. > > For: > > MAC = MAC_algo (Traffic_Key, Message) > > > HMAC-SHA-1-96 for TCP-AO has the following values: > > > - MAC_algo: HMAC-SHA1 > - Traffic_Key: Variable; the result of the KDF. > - Message: The message to be authenticated, as specified in > [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. > > > >3.2.2. The Use of AES-128-CMAC-96 > > In the context of TCP-AO, when we say "AES-128-CMAC-96" we actually > define a usage of AES-128 as a cipher-based MAC according to > [NIST-SP800-38B]. > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 11] > >Internet-Draft Crypto for TCP-AO October 2009 > > > The three fixed elements for AES-128-CMAC-96 are: > > - KDF_Algo: KDF_AES_128_CMAC. > - Key_Length: 128 bits. > - Output: 96 bits. > > For: > > MAC = MAC_algo (Traffic_Key, Message) > > > AES-128-CMAC-96 for TCP-AO has the following values: > > > - MAC_algo: AES-128-CMAC-96 [RFC4493] > - Traffic_Key: Variable; the result of the KDF. > - Message: The message to be authenticated, as specified in > [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. > > > > >4. Change History (RFC Editor: Delete before publishing) > > [NOTE TO RFC EDITOR: this section for use during I-D stage only. > Please remove before publishing as RFC.] > > draft-ietf...-01 - 5th submission > > o structure of sect 3 changed: 3.1 becomes "Concrete KDF's" and the > description of the two KDF's became 3.1.1.1 & 3.1.1.2. used a > template (of sorts) in both sections that can be easily re-used by > any future KDF definition. > o in 3.1, for Derived_Key definition, changed the name of the > element "Input" to "Context", and removed the hard binding to > NIST-SP800-108 at the generic interface level. The NIST inclusion > is still present in the concrete definitions of the two presented > KDF's, but this way, if NIST changes, or if the community wants to > define some other, non-NIST-like KDFs, the interface is flexible > enough to handle that. Changed "KDF" to "KDF-alg". > o in 3.2, clarified that the output of the function is called "MAC > =", to have a similar look and feel to sect 3.1's function. also > changed MAC(foo) to "MAC_alg", and dropped "Output_Length" from > the function parameters, as it is specified as a fixed element for > each MAC defined, but not passed as a parameter of the function. > o sect 3.2 - removed "truncation" from interface definition, and > placed it as a fixed element of the MAC definition. sect 3.2.1 and > 3.2.2 - changed "truncation:" field to "Output:". Removed text > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 12] > >Internet-Draft Crypto for TCP-AO October 2009 > > > about RFC4493 from end of 3.2.2. > o sect 3.1.1.2, changed back to follow 4615 exactly (agreement with > polk, mcgrew, lebovitz, ekr) > o sect 3.1.1.3, deleted the following: "When such a time arrives as > KDF_AES_128_CMAC becomes widely deployed, this document should be > updated so that it becomes the default KDF on implementations." > o Minor text change in section 3.1 and 3.2, to the definition of > "Context" in both - Joe Touch > o minor text change in 3.1.1 clarifying that the concatenation is of > binary strings - Joe Touch > > draft-ietf...-00 - 4th submission > > o Submitting draft-lebovitz...-02 as a WG document. Added EKR as > co- author, and gave him credit for rewrite of sect 3.1.x . > > lebovitz...-02 - 3rd submission > > o cleaned up explanation in 3.1.2 > o in 3.1.2, changed the key extractor mechanism back, from using an > alphanumeric string for the fixed key C to use 0^128 as the key > (as it was in -00) (Polk & Ekr) > o deleted cut-and-paste error text from sect 3.1 between "label" and > "context" > o changed "conn_key" to "traffic_key" throughout, to follow auth- > opt-05 > o changed "tsad" to "mkt" throughout, to follow auth-opt-05 > o changed "conn_block" to "data_block" throughout, to follow auth- > opt-05 > > lebovitz...-01- 2nd submission > > o removed the whole section on labels (previously section 4), per WG > consensus at IETF74. Added 3.1.3 to specify that implementations > SHOULD make HMAC-SHA1 the default choice for the time being, and > to suggest common names for the KDF's universally in UI's. > o changed KDF = PRF... to Derived_Key = KDF... (EKR) > o added the text on how to deal with future KDF to end of s3.1 (EKR) > o removed references to TCP-AO "manual key mode". Changed to TCP- > AO's "current mode of manual keying". (Touch) > o removed the whole MUST- / SHOULD+ thing. Both KDF's are MUST now, > per wg consensus at ietf74. > o in 3.1.2, changed the mechanism to force the K to be 128bits from > using 0^128, to using a fixed 128-bit string of random characters > (Dave McGrew) > o sect 3.1, in Input description, dropped "0x00". Added "NOTE" > explaining why right after the output_length description. > > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 13] > >Internet-Draft Crypto for TCP-AO October 2009 > > > o cleaned up all references > o copy editing > > lebovitz...-00 - original submission > > >5. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) > > [NOTE TO RFC EDITOR: this section for use during I-D stage only. > Please remove before publishing as RFC.] > > List of stuff that still needs work > o should be ready for WG LC. Any changes will come from final WG > review or IESG review. > > >6. Security Considerations > > This document inherits all of the security considerations of the > TCP-AO, the AES-CMAC, and the HMAC-SHA-1 documents. > > The security of cryptographic-based systems depends on both the > strength of the cryptographic algorithms chosen and the strength of > the keys used with those algorithms. The security also depends on > the engineering of the protocol used by the system to ensure that > there are no non-cryptographic ways to bypass the security of the > overall system. > > Care should also be taken to ensure that the selected key is > unpredictable, avoiding any keys known to be weak for the algorithm > in use. ][RFC4086] contains helpful information on both key > generation techniques and cryptographic randomness. > > Note that in the composition of KDF_AES_128_CMAC, the PRF needs a 128 > bit / 16 byte key as the seed. However, for convenience to the > administrators/deployers, we did not want to force them to enter a 16 > byte Master_Key. So we specified the sub-key routine that could > handle a variable length Master_Key, one that might be less than 16 > bytes. This does NOT mean that administrators are safe to use weak > keys. Administrators are encouraged to follow [RFC4086] as listed > above. We simply attempted to "put a fence around stupidity", in as > much as possible. > > This document concerns itself with the selection of cryptographic > algorithms for the use of TCP-AO. The algorithms identified in this > document as "MUST implement" or "SHOULD implement" are not known to > be broken at the current time, and cryptographic research so far > leads us to believe that they will likely remain secure into the > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 14] > >Internet-Draft Crypto for TCP-AO October 2009 > > > foreseeable future. Some of the algorithms may be found in the > future to have properties significantly weaker than those that were > believed at the time this document was produced. Expect that new > revisions of this document will be issued from time to time. Be sure > to search for more recent versions of this document before > implementing. > > >7. IANA Considerations > > IANA has created and will maintain a registry called, "Cryptographic > Algorithms for TCP-AO". The registry consists of a text string and > an RFC number that lists the associated transform(s). New entries > can be added to the registry only after RFC publication and approval > by an expert designated by the IESG. > > The registry has the following initial values: > > > SHA1 [This RFC when published] > AES128 [This RFC when published] > > > >8. Acknowledgements > > Eric "EKR" Rescorla, who provided a ton of input and feedback, > including a somewhat heavy re-write of section 3.1.x, earning him and > author slot on the document. > > Paul Hoffman, from whose [RFC4308] I sometimes copied, to quickly > create a first draft here. > > Tim Polk, whose email summarizing SAAG's guidance to TCPM on the two > hash algorithms for TCP-AO is largely cut and pasted into various > sections of this document. > > Jeff Schiller, Donald Eastlake and the IPsec WG, whose [RFC4307] & > [RFC4305] text was consulted and sometimes used in the Requirements > Section 2 section of this document. > > (In other words, I was truly only an editor of others' text in > creating this document.) > > Eric "EKR" Rescorla and Brian Weis, who brought to clarity the issues > with the inputs to PRFs for the KDFs. EKR was also of great > assistance in how to structure the text, as well as helping to guide > good cryptographic decisions. > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 15] > >Internet-Draft Crypto for TCP-AO October 2009 > > > The TCPM working group, who put up with all us crypto and routing > folks DoS'ing their WG for 2 years, and who provided reviews of this > document. > > >9. References > >9.1. Normative References > > [I-D.ietf-tcpm-tcp-auth-opt] > Touch, J., Mankin, A., and R. Bonica, "The TCP > Authentication Option", draft-ietf-tcpm-tcp-auth-opt-05 > (work in progress), July 2009. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > >9.2. Informative References > > [HMAC-ATTACK] > "On the Security of HMAC and NMAC Based on HAVAL, MD4, > MD5, SHA-0 and SHA-1"", 2006, > http://www.springerlink.com/content/00w4v62651001303>. > > [I-D.narten-iana-considerations-rfc2434bis] > Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", > draft-narten-iana-considerations-rfc2434bis-09 (work in > progress), March 2008. > > [NIST-SP800-108] > National Institute of Standards and Technology, > "Recommendation for Key Derivation Using Pseudorandom > Functions", SP 800-108, April 2008. > > [NIST-SP800-38B] > National Institute of Standards and Technology, > "Recommendation for Block Cipher Modes of Operation: The > CMAC Mode for Authentication", SP 800-38B, May 2005. > > [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- > Hashing for Message Authentication", RFC 2104, > February 1997. > > [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the > Internet Protocol", RFC 2401, November 1998. > > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 16] > >Internet-Draft Crypto for TCP-AO October 2009 > > > [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within > ESP and AH", RFC 2404, November 1998. > > [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security > Payload (ESP)", RFC 2406, November 1998. > > [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness > Requirements for Security", BCP 106, RFC 4086, June 2005. > > [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation > Requirements for Encapsulating Security Payload (ESP) and > Authentication Header (AH)", RFC 4305, December 2005. > > [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the > Internet Key Exchange Version 2 (IKEv2)", RFC 4307, > December 2005. > > [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, > December 2005. > > [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The > AES-CMAC Algorithm", RFC 4493, June 2006. > > [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The > Advanced Encryption Standard-Cipher-based Message > Authentication Code-Pseudo-Random Function-128 (AES-CMAC- > PRF-128) Algorithm for the Internet Key Exchange Protocol > (IKE)", RFC 4615, August 2006. > > >Authors' Addresses > > Gregory Lebovitz > Juniper Networks, Inc. > 1194 North Mathilda Ave. > Sunnyvale, CA 94089-1206 > US > > Phone: > Email: gregory.ietf@gmail.com > > > > > > > > > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 17] > >Internet-Draft Crypto for TCP-AO October 2009 > > > Eric Rescorla > RTFM, Inc. > 2064 Edgewood Drive > Palo Alto, CA 94303 > US > > Phone: 650-678-2350 > Email: ekr@rtfm.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Lebovitz & Rescorla Expires April 29, 2010 [Page 18] > > > >+++++++++++++++++++++++ >IETF-related email from >Gregory M. Lebovitz >Juniper Networks >g r e go r y d o t i e tf a t g m a i l do t c o m --=====================_37082250==.ALT Content-Type: text/html; charset="us-ascii" Hey all,
Below pls find pasted the latest version of
   draft-ietf-tcpm-tcp-ao-crypto-01

This one should be ready for WG LC. I'll let the WG Chairs make that call.

It did not include a change log, but here are the changes:
 - simplified title of document - Touch
 - copy edits for read-ability throughout - Touch
 - switched "Derived_Key" back to "Traffic_Key" in order to sync with -AO spec.
 - added the two IANA values SHA1 and AES128 to IANA section

I missed the cutoff for I-D submission, but have asked Lars (AD) to intervene. Hopefully he can get it published to the repository with a manual push.

Gregory.

At 07:12 PM 10/26/2009, you wrote:
Attached are the .txt and .xml for the version of draft-ietf-tcpm-tcp-ao-crypto-01 document, which should be ready for WG Last Call. It contains all the latest feedback from reviews by Touch and EKR. I missed the I-D deadline by 2 hours...  ughh. The text of  the draft is pasted below, for convenience.

Lars, can you push this through the I-D editor queue for us??

Gregory.
= = = = BEGIN PASTED TEXT; view in fixed width font = = = =



TCPM                                                         G. Lebovitz
Internet-Draft                                                   Juniper
Intended status: Standards Track                             E. Rescorla
Expires: April 29, 2010                                             RTFM
                                                        October 26, 2009


    Cryptographic Algorithms for TCP's Authentication Option, TCP-AO
                    draft-ietf-tcpm-tcp-ao-crypto-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 29, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Lebovitz & Rescorla      Expires April 29, 2010                 [Page 1]

Internet-Draft              Crypto for TCP-AO               October 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document ( http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The TCP Authentication Option, TCP-AO, relies on security algorithms
   to provide authentication between two end-points.  There are many
   such algorithms available, and two TCP-AO systems cannot interoperate
   unless they are using the same algorithm(s).  This document specifies
   the algorithms and attributes that can be used in TCP-AO's current
   manual keying mechanism.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
     2.2.  Algorithm Requirements . . . . . . . . . . . . . . . . . .  3
     2.3.  Requirements for Future MAC Algorithms . . . . . . . . . .  4
   3.  Algorithms Specified . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Key Derivation Functions (KDFs)  . . . . . . . . . . . . .  5
       3.1.1.  Concrete KDFs  . . . . . . . . . . . . . . . . . . . .  6
     3.2.  MAC Algorithms . . . . . . . . . . . . . . . . . . . . . . 10
       3.2.1.  The Use of HMAC-SHA-1-96 . . . . . . . . . . . . . . . 11
       3.2.2.  The Use of AES-128-CMAC-96 . . . . . . . . . . . . . . 11
   4.  Change History (RFC Editor: Delete before publishing)  . . . . 12
   5.  Needs Work in Next Draft (RFC Editor: Delete Before
       Publishing)  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17












Lebovitz & Rescorla      Expires April 29, 2010                 [Page 2]

Internet-Draft              Crypto for TCP-AO               October 2009


1.  Introduction

   This document is a companion to TCP-AO [TCP-AO]
   [I-D.ietf-tcpm-tcp-auth-opt].  Like most modern security protocols,
   TCP-AO allows users to chose which cryptographic algorithm(s) they
   want to use to meet their security needs.

   TCP-AO provides cryptographic authentication and message integrity
   verification between to end-points.  In order to accomplish this
   function, message authentication codes (MACs) are used, which then
   rely on shared keys.  There are various ways to create MACs.  The use
   of hashed-based MACs (HMAC) in Internet protocols is defined in
   [RFC2104].  The use of cipher-based MACs (CMAC) in Internet protocols
   is defined in [RFC4493].

   This RFC defines the general requirements for MACs used in TCP-AO,
   both for currently specified MACs and for any future specified MACs.
   It then specifies two MAC algorithms required in all TCP-AO
   implementations.  It also specifies two key derivations functions
   (KDFs) used to create the traffic keys used by the MACs.  These KDFs
   are also required by all TCP-AO implementations.


2.  Requirements

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   When used in lower case, these words convey their typical use in
   common language, and are not to be interpreted as described in
   [RFC2119].

2.2.  Algorithm Requirements

   This is the initial specification of required cryptography for
   TCP-AO, and indicates two MAC algorithms and two KDFs.  All four
   components MUST be implemented in order for the implementation to be
   fully compliant with this RFC.

   The following table indicates the required MAC algorithms and KDFs
   for TCP-AO:







Lebovitz & Rescorla      Expires April 29, 2010                 [Page 3]

Internet-Draft              Crypto for TCP-AO               October 2009


           Requirement      Authentication Algorithm
           ------------     ------------------------
           MUST             HMAC-SHA-1-96 [RFC2404]
           MUST             AES-128-CMAC-96 [RFC4493]

           Requirement      Key Derivation Function (KDF)
           -------------    ------------------------
           MUST             KDF_HMAC_SHA1
           MUST             KDF_AES_128_CMAC

   NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED:

   Two MAC algorithms and two corresponding KDFs are mandated as a
   result of discussion in the TCPM WG, and in consultation with the
   Security Area Directors.  SHA-1 was selected because it is widely
   deployed and currently has sufficient strength and reasonable
   computational cost, so it is a "MUST" for TCP-AO today.  The security
   strength of SHA-1 HMACs should be sufficient for the foreseeable
   future, especially given that the tags are truncated to 96 bits.

   Recently exposed vulnerabilities in other MACs (e.g., MD5 or HMAC
   MD5) aren't practical on SHA-1, but these types of analyses are
   mounting and could potentially pose a concern for HMAC forgery if
   they were significantly improved, over time.  The security issues
   driving the migration from SHA-1 to SHA-256 for digital signatures
   [HMAC-ATTACK] do not immediately render SHA-1 weak for this
   application of SHA-1 in HMAC mode.

   AES-128 CMAC is considered to be a stronger algorithm than SHA-1, but
   may not yet have very wide implementation.  AES-128 CMAC is also a
   "MUST" to implement, in order to drive vendors toward its use, and to
   allow for another MAC option, if SHA-1 were to be compromised.

2.3.  Requirements for Future MAC Algorithms

   TCP-AO is intended to support cryptographic agility.  As a result,
   this document includes recommendations in various places for future
   MAC and KDF algorithms when used for TCP-AO.  For future MAC
   algorithms specifically, they SHOULD protect at least 2**48 messages
   with a collision probability of less than one in 10**9.

   [Reviewers: Are there any other requirements we want/need to place in
   here?  RFC EDITOR: Please delete this note before publishing as RFC]


3.  Algorithms Specified

   TCP-AO requires two classes of cryptographic algorithms used on a



Lebovitz & Rescorla      Expires April 29, 2010                 [Page 4]

Internet-Draft              Crypto for TCP-AO               October 2009


   particular connection, and refers to this document to define them
   both:


       (1)  Key Derivation Functions (KDFs) which name a pseudorandom
            function (PRF) and use a Master_Key and some connection-
            specific input with that PRF to produce Traffic_Keys, the
            keys suitable for authenticating and integrity checking
            individual TCP segments, as described in TCP-AO.
       (2)  Message Authentication Code (MAC) algorithms which take a
            key and a message and produce an authentication tag which
            can be used to verify the integrity and authenticity of
            those messages.

   In TCP-AO, these algorithms are always used in pairs.  Each MAC
   algorithm MUST specify the KDF to be used with that MAC algorithm.
   However, a KDF MAY be used with more than one MAC algorithm.

3.1.  Key Derivation Functions (KDFs)

   TCP-AO's Traffic_Keys are derived using KDFs.  The KDFs used in TCP-
   AO's current manual keying have the following interface:

       Traffic_Key = KDF_algo(Master_Key, Context, Output_Length)

   where:


      - KDF_algo:    the specific pseudorandom function (PRF) that is
                     the basic building block used in constructing the
                     given Traffic_Key.

      - Master_Key:  In TCP-AO's manual key mode, this is a key shared
                     by both peers, entered via some interface to their
                     respective configurations.  The Master_Key is used
                     as the seed for the KDF.  We assume that this is a
                     human-readable pre-shared key (PSK), thus we assume
                     it is of variable length.  Master_Keys SHOULD be
                     random, but might not be (e.g., badly chosen by the
                     user).

      - Context :    A binary string containing information related to
                     the specific connection for this derived keying
                     material.  TCP-AO specifies the content of the
                     Context, which includes things like the TCP segment
                     prepended by the TCP pseudoheader and TCP header
                     options, as defined in
                     [I-D.ietf-tcpm-tcp-auth-opt], Section 7.2]



Lebovitz & Rescorla      Expires April 29, 2010                 [Page 5]

Internet-Draft              Crypto for TCP-AO               October 2009



      - Output_Length:  The length in bits of the key that the KDF will
                     produce.  This length must be the size required for
                     the MAC algorithm that will use the PRF result as a
                     seed.

   When invoked, a KDF generates a string of length Output_Length bits
   based on Master_Key and context value.  This result may then be used
   as a cryptographic key for any algorithm which takes an Output_Length
   length key.  A KDF MAY specify a maximum Output_Length parameter.

3.1.1.  Concrete KDFs

   This document defines two KDF algorithms, each paired with a
   corresponding PRF algorithm as explained below:


       *  KDF_HMAC_SHA1  based on PRF-HMAC-SHA1 [RFC2404]
       *  KDF_AES_128_CMAC  based on AES-CMAC-PRF-128 [RFC4615]


   Each

   Both of these KDFs are based on the iteration mode KDFs specified in
   [NIST-SP800-108].  This means that they use an underlying
   pseudorandom function (PRF) with a fixed-length output lengths, 128
   bits in the case of the AES-CMAC, and 160 bits in the case of HMAC-
   SHA1.  The KDF generates an arbitrary number of output bits by
   operating the PRF in a "counter mode", where each invocation of the
   PRF uses a different input block differentiated by a block counter.

   Each input block is constructed as follows:

        ( i || Label || Context || Output_Length)

      Where

      - "||":      For any X || Y, "||" represents a concatonation
                   operation of the binary strings X and Y.

      - i:         A counter, a binary string that is an input to each
                   iteration of the PRF in counter mode.  The number of
                   iterations will depend on the specific size of the
                   Output_Length desired for a given MAC.







Lebovitz & Rescorla      Expires April 29, 2010                 [Page 6]

Internet-Draft              Crypto for TCP-AO               October 2009



      - Label:     A binary string that clearly identifies the purpose
                   of this KDF's derived keying material.  For TCP-AO we
                   use the ASCII string "TCP-AO", where the last
                   character is the capital letter "O", not to be
                   confused with a zero.  While this may seem like
                   overkill in this specification since TCP-AO only
                   describes one call to the KDF, it is included in
                   order to comply with FIPS 140 certifications.

      - Context :  The context argument provided to the KDF interface,
                   as described above in Section 3.1 .

      - Output_Length:  The length in bits of the key that the KDF will
                   produce.  This length must be the size required for
                   the MAC algorithm that will use the PRF result as a
                   seed.

   The ouput of mutiple PRF invocations is simply concatenated.  For the
   Traffic_Key, values of multiple PRF invocations are concatenated and
   truncated as needed to create a Traffic_Key of the desired length.
   For instance, if one were using KDF_HMAC_SHA1, which uses a 160-bit
   internal PRF to generate 320 bits of data, one would execute the PRF
   twice, once with i=0 and once with i=1.  The result would be the
   entire output of the first invocation concatenated with the second
   invocation.  E.g.,

          Traffic_Key =
            KDF_algo(Master_Key, 0 || Label || Context || Output_length) ||
            KDF_algo(Master_Key, 1 || Label || Context || Output_length)

   If the number of bits required is not an even multiple of the output
   size of the PRF, then the output of the final invocation of the PRF
   is truncated as necessary.

3.1.1.1.  KDF_HMAC_SHA1

   For KDF_HMAC_SHA1:

   - PRF:       HMAC-SHA1 [RFC2404].

   - Use:       HMAC-SHA1(Key, Input).

   - Key:       Master_Key, configured by user, and passed to the KDF.







Lebovitz & Rescorla      Expires April 29, 2010                 [Page 7]

Internet-Draft              Crypto for TCP-AO               October 2009



   - Input:     ( i || Label || Context || Output_Length)

   - Output_Length:  160 bits.

   - Result:    Traffic_Key, used in the MAC function by TCP-AO.

3.1.1.2.  KDF_AES_128_CMAC

   For KDF_AES_128_CMAC:

   - PRF:       AES-CMAC-PRF-128 [RFC4615].

   - Use:       AES-CMAC(Key, Input).

   - Key:       Traffic_Master_Key (see below)

   - Input:     ( i || Label || Context || Output_Length)

   - Output_Length:  128 bits.

   - Result:    Traffic_Key, used in the MAC function by TCP-AO

   The Master_Key in TCP-AO's current manual keying mechanism is a
   shared secret, entered by an administrator.  It is passed via an out-
   of-band mechanism between two devices, and often between two
   organizations.  The shared secret does not have to be 16 octets, and
   the length may vary.  However, AES_128_CMAC requires a key of exactly
   16 octets (128 bits) in length.  We could mandate that
   implementations force administrators to input Master_Keys of exactly
   128 bit length when using AES_128_CMAC, and with sufficient
   randomness, but this places undue burden on the implementors and
   deployers.  This specification RECOMMENDS that deployers use a
   randomly generated 128-bit string as the Master_Key, but acknowledges
   that deployers may not.

   To handle variable length Master_Keys we use the same mechanism as
   described in [RFC4615], Sect 3.  First we use AES_128_CMAC with a
   fixed key of all zeros as a "randomness extractor", while using the
   shared secret Master_Key, MK, as the message input, to produce a 128
   bit key Derived_Master_Key (K).  Second, we use the result as a key,
   and run AES-128_CMAC again, this time using the result K as the Key,
   and the true input block as the Input to yield the Traffic_Key (TK)
   used in the MAC over the message.  The description follows:







Lebovitz & Rescorla      Expires April 29, 2010                 [Page 8]

Internet-Draft              Crypto for TCP-AO               October 2009


          +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   +                        KDF-AES-128-CMAC                           +
   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   +                                                                   +
   + Input  : MK (Master_Key, the variable-length shared secret)       +
   +        : I (Input, i.e., the input data of the PRF)               +
   +        : MKlen (length of MK in octets)                           +
   +        : len (length of M in octets)                              +
   + Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable)+
   +                                                                   +
   +-------------------------------------------------------------------+
   + Variable: K (128-bit key for AES-CMAC)                            +
   +                                                                   +
   + Step 1.   If MKlen is equal to 16                                 +
   + Step 1a.  then                                                    +
   +               K := MK;                                            +
   + Step 1b.  else                                                    +
   +               K := AES-CMAC(0^128, MK, MKlen);                    +
   + Step 2.   TK := AES-CMAC(K, I, len);                             +
   +           return TK;                                             +
   +                                                                   +
   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


                                 Figure 1

   In step 1, the 128-bit key, K, for AES-CMAC is derived as follows:

   o If the Master_Key, MK, provided by the administrator is exactly 128
   bits, then we use it as-is.

   o If it is longer or shorter than 128 bits, then we derive the key K
   by applying the AES-CMAC algorithm using the 128-bit all-zero string
   as the key and MK as the input message.  This step is described in
   step 1b.

   In step 2, we apply the AES-CMAC algorithm again, this time using K
   as the key and I as the input message.

   The output of this algorithm returns TK, the Traffic_Key, which is
   128 bits suitable for use in the MAC function on each TCP segment of
   the connection.

3.1.1.3.  Tips for User Interfaces regarding KDFs

   This section provides suggested representations for the KDFs in
   implementation user interfaces.  Following these guidelines across
   common implementations will make interoperability easier and simpler



Lebovitz & Rescorla      Expires April 29, 2010                 [Page 9]

Internet-Draft              Crypto for TCP-AO               October 2009


   for deployers.

   UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply "SHA1".

   UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply
   "AES128".

   The initial IANA registry values will reflect these two entries.

   UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO
   settings.  KDF_HMAC_SHA1 is preferred at this time because it has
   wide support, being present in most implementations in the
   marketplace.

3.2.  MAC Algorithms

   Each MAC_algo defined for TCP-AO has three fixed elements as part of
   its definition:

   - KDF_Algo:    Name of the TCP-AO KDF algorithm used to generate the
                  Traffic_Key
   - Key_Length:  Length in bits required for the Traffic_Key used in
                  this MAC
   - Output:      The final length of the bits used in the TCP-AO MAC
                  field.  This value may be a truncation of the MAC
                  function's original output length.

   MACs computed for TCP-AO have the following interface:

       MAC = MAC_algo(Traffic_Key, Message)

   where:


      - MAC_algo:    MAC Algorithm used
      - Traffic_Key: Variable; the result of KDF.
      -  Message     The message to be authenticated, as specified in
                     [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1.

   This document specifies two MAC algorithm options for generating the
   MAC as used by TCP-AO:


       *  HMAC-SHA-1-96  based on [RFC2404]







Lebovitz & Rescorla      Expires April 29, 2010                [Page 10]

Internet-Draft              Crypto for TCP-AO               October 2009



       *  AES-128-CMAC-96  based on [RFC4493]

   Both provide a high level of security and efficiency.  The AES-128-
   CMAC-96 is potentially more efficient, particularly in hardware, but
   HMAC-SHA-1-96 is more widely used in Internet protocols and in most
   cases could be supported with little or no additional code in today's
   deployed software and devices.

   An important aspect to note about these algorithms' definitions for
   use in TCP-AO is the fact that the MAC outputs are truncated to 96
   bits.  AES-128-CMAC-96 produces a 128 bit MAC, and HMAC SHA-1
   produces a 160 bit result.  The MAC output are then truncated to 96
   bits to provide a reasonable tradeoff between security and message
   size, for fitting into the TCP-AO header.

3.2.1.  The Use of HMAC-SHA-1-96

   By definition, HMAC [RFC2104] requires a cryptographic hash function.
   SHA1 will be that has function used for authenticating and providing
   integrity validation on TCP segments with HMAC.

   The three fixed elements for HMAC-SHA-1-96 are:

   - KDF_Algo:    KDF_HMAC_SHA1.
   - Key_Length:  160 bits.
   - Output:      96 bits.

   For:

        MAC = MAC_algo (Traffic_Key, Message)


   HMAC-SHA-1-96 for TCP-AO has the following values:


      - MAC_algo:    HMAC-SHA1
      - Traffic_Key: Variable; the result of the KDF.
      - Message:     The message to be authenticated, as specified in
                     [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1.



3.2.2.  The Use of AES-128-CMAC-96

   In the context of TCP-AO, when we say "AES-128-CMAC-96" we actually
   define a usage of AES-128 as a cipher-based MAC according to
   [NIST-SP800-38B].



Lebovitz & Rescorla      Expires April 29, 2010                [Page 11]

Internet-Draft              Crypto for TCP-AO               October 2009


   The three fixed elements for AES-128-CMAC-96 are:

   - KDF_Algo:    KDF_AES_128_CMAC.
   - Key_Length:  128 bits.
   - Output:      96 bits.

   For:

        MAC = MAC_algo (Traffic_Key, Message)


   AES-128-CMAC-96 for TCP-AO has the following values:


      - MAC_algo:    AES-128-CMAC-96 [RFC4493]
      - Traffic_Key: Variable; the result of the KDF.
      - Message:     The message to be authenticated, as specified in
                     [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1.




4.  Change History (RFC Editor: Delete before publishing)

   [NOTE TO RFC EDITOR: this section for use during I-D stage only.
   Please remove before publishing as RFC.]

   draft-ietf...-01 - 5th submission

   o  structure of sect 3 changed: 3.1 becomes "Concrete KDF's" and the
      description of the two KDF's became 3.1.1.1 & 3.1.1.2. used a
      template (of sorts) in both sections that can be easily re-used by
      any future KDF definition.
   o  in 3.1, for Derived_Key definition, changed the name of the
      element "Input" to "Context", and removed the hard binding to
      NIST-SP800-108 at the generic interface level.  The NIST inclusion
      is still present in the concrete definitions of the two presented
      KDF's, but this way, if NIST changes, or if the community wants to
      define some other, non-NIST-like KDFs, the interface is flexible
      enough to handle that.  Changed "KDF" to "KDF-alg".
   o  in 3.2, clarified that the output of the function is called "MAC
      =", to have a similar look and feel to sect 3.1's function. also
      changed MAC(foo) to "MAC_alg", and dropped "Output_Length" from
      the function parameters, as it is specified as a fixed element for
      each MAC defined, but not passed as a parameter of the function.
   o  sect 3.2 - removed "truncation" from interface definition, and
      placed it as a fixed element of the MAC definition. sect 3.2.1 and
      3.2.2 - changed "truncation:" field to "Output:".  Removed text



Lebovitz & Rescorla      Expires April 29, 2010                [Page 12]

Internet-Draft              Crypto for TCP-AO               October 2009


      about RFC4493 from end of 3.2.2.
   o  sect 3.1.1.2, changed back to follow 4615 exactly (agreement with
      polk, mcgrew, lebovitz, ekr)
   o  sect 3.1.1.3, deleted the following: "When such a time arrives as
      KDF_AES_128_CMAC becomes widely deployed, this document should be
      updated so that it becomes the default KDF on implementations."
   o  Minor text change in section 3.1 and 3.2, to the definition of
      "Context" in both - Joe Touch
   o  minor text change in 3.1.1 clarifying that the concatenation is of
      binary strings - Joe Touch

   draft-ietf...-00 - 4th submission

   o  Submitting draft-lebovitz...-02 as a WG document.  Added EKR as
      co- author, and gave him credit for rewrite of sect 3.1.x .

   lebovitz...-02 - 3rd submission

   o  cleaned up explanation in 3.1.2
   o  in 3.1.2, changed the key extractor mechanism back, from using an
      alphanumeric string for the fixed key C to use 0^128 as the key
      (as it was in -00) (Polk & Ekr)
   o  deleted cut-and-paste error text from sect 3.1 between "label" and
      "context"
   o  changed "conn_key" to "traffic_key" throughout, to follow auth-
      opt-05
   o  changed "tsad" to "mkt" throughout, to follow auth-opt-05
   o  changed "conn_block" to "data_block" throughout, to follow auth-
      opt-05

   lebovitz...-01- 2nd submission

   o  removed the whole section on labels (previously section 4), per WG
      consensus at IETF74.  Added 3.1.3 to specify that implementations
      SHOULD make HMAC-SHA1 the default choice for the time being, and
      to suggest common names for the KDF's universally in UI's.
   o  changed KDF = PRF... to Derived_Key = KDF...  (EKR)
   o  added the text on how to deal with future KDF to end of s3.1 (EKR)
   o  removed references to TCP-AO "manual key mode".  Changed to TCP-
      AO's "current mode of manual keying".  (Touch)
   o  removed the whole MUST- / SHOULD+ thing.  Both KDF's are MUST now,
      per wg consensus at ietf74.
   o  in 3.1.2, changed the mechanism to force the K to be 128bits from
      using 0^128, to using a fixed 128-bit string of random characters
      (Dave McGrew)
   o  sect 3.1, in Input description, dropped "0x00".  Added "NOTE"
      explaining why right after the output_length description.




Lebovitz & Rescorla      Expires April 29, 2010                [Page 13]

Internet-Draft              Crypto for TCP-AO               October 2009


   o  cleaned up all references
   o  copy editing

   lebovitz...-00 - original submission


5.  Needs Work in Next Draft (RFC Editor: Delete Before Publishing)

   [NOTE TO RFC EDITOR: this section for use during I-D stage only.
   Please remove before publishing as RFC.]

   List of stuff that still needs work
   o  should be ready for WG LC.  Any changes will come from final WG
      review or IESG review.


6.  Security Considerations

   This document inherits all of the security considerations of the
   TCP-AO, the AES-CMAC, and the HMAC-SHA-1 documents.

   The security of cryptographic-based systems depends on both the
   strength of the cryptographic algorithms chosen and the strength of
   the keys used with those algorithms.  The security also depends on
   the engineering of the protocol used by the system to ensure that
   there are no non-cryptographic ways to bypass the security of the
   overall system.

   Care should also be taken to ensure that the selected key is
   unpredictable, avoiding any keys known to be weak for the algorithm
   in use. ][RFC4086] contains helpful information on both key
   generation techniques and cryptographic randomness.

   Note that in the composition of KDF_AES_128_CMAC, the PRF needs a 128
   bit / 16 byte key as the seed.  However, for convenience to the
   administrators/deployers, we did not want to force them to enter a 16
   byte Master_Key. So we specified the sub-key routine that could
   handle a variable length Master_Key, one that might be less than 16
   bytes.  This does NOT mean that administrators are safe to use weak
   keys.  Administrators are encouraged to follow [RFC4086] as listed
   above.  We simply attempted to "put a fence around stupidity", in as
   much as possible.

   This document concerns itself with the selection of cryptographic
   algorithms for the use of TCP-AO.  The algorithms identified in this
   document as "MUST implement" or "SHOULD implement" are not known to
   be broken at the current time, and cryptographic research so far
   leads us to believe that they will likely remain secure into the



Lebovitz & Rescorla      Expires April 29, 2010                [Page 14]

Internet-Draft              Crypto for TCP-AO               October 2009


   foreseeable future.  Some of the algorithms may be found in the
   future to have properties significantly weaker than those that were
   believed at the time this document was produced.  Expect that new
   revisions of this document will be issued from time to time.  Be sure
   to search for more recent versions of this document before
   implementing.


7.  IANA Considerations

   IANA has created and will maintain a registry called, "Cryptographic
   Algorithms for TCP-AO".  The registry consists of a text string and
   an RFC number that lists the associated transform(s).  New entries
   can be added to the registry only after RFC publication and approval
   by an expert designated by the IESG.

   The registry has the following initial values:


      SHA1           [This RFC when published]
      AES128         [This RFC when published]



8.  Acknowledgements

   Eric "EKR" Rescorla, who provided a ton of input and feedback,
   including a somewhat heavy re-write of section 3.1.x, earning him and
   author slot on the document.

   Paul Hoffman, from whose [RFC4308] I sometimes copied, to quickly
   create a first draft here.

   Tim Polk, whose email summarizing SAAG's guidance to TCPM on the two
   hash algorithms for TCP-AO is largely cut and pasted into various
   sections of this document.

   Jeff Schiller, Donald Eastlake and the IPsec WG, whose [RFC4307] &
   [RFC4305] text was consulted and sometimes used in the Requirements
   Section 2 section of this document.

   (In other words, I was truly only an editor of others' text in
   creating this document.)

   Eric "EKR" Rescorla and Brian Weis, who brought to clarity the issues
   with the inputs to PRFs for the KDFs.  EKR was also of great
   assistance in how to structure the text, as well as helping to guide
   good cryptographic decisions.



Lebovitz & Rescorla      Expires April 29, 2010                [Page 15]

Internet-Draft              Crypto for TCP-AO               October 2009


   The TCPM working group, who put up with all us crypto and routing
   folks DoS'ing their WG for 2 years, and who provided reviews of this
   document.


9.  References

9.1.  Normative References

   [I-D.ietf-tcpm-tcp-auth-opt]
              Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", draft-ietf-tcpm-tcp-auth-opt-05
              (work in progress), July 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [HMAC-ATTACK]
              "On the Security of HMAC and NMAC Based on HAVAL, MD4,
              MD5, SHA-0 and SHA-1"", 2006,
              <http://eprint.iacr.org/2006/187
              http://www.springerlink.com/content/00w4v62651001303>.

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-09 (work in
              progress), March 2008.

   [NIST-SP800-108]
              National Institute of Standards and Technology,
              "Recommendation for Key Derivation Using Pseudorandom
              Functions", SP 800-108, April 2008.

   [NIST-SP800-38B]
              National Institute of Standards and Technology,
              "Recommendation for Block Cipher Modes of Operation: The
              CMAC Mode for Authentication", SP 800-38B, May 2005.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.




Lebovitz & Rescorla      Expires April 29, 2010                [Page 16]

Internet-Draft              Crypto for TCP-AO               October 2009


   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, November 1998.

   [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4305]  Eastlake, D., "Cryptographic Algorithm Implementation
              Requirements for Encapsulating Security Payload (ESP) and
              Authentication Header (AH)", RFC 4305, December 2005.

   [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the
              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
              December 2005.

   [RFC4308]  Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308,
              December 2005.

   [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
              AES-CMAC Algorithm", RFC 4493, June 2006.

   [RFC4615]  Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
              Advanced Encryption Standard-Cipher-based Message
              Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
              PRF-128) Algorithm for the Internet Key Exchange Protocol
              (IKE)", RFC 4615, August 2006.


Authors' Addresses

   Gregory Lebovitz
   Juniper Networks, Inc.
   1194 North Mathilda Ave.
   Sunnyvale, CA  94089-1206
   US

   Phone:
   Email: gregory.ietf@gmail.com











Lebovitz & Rescorla      Expires April 29, 2010                [Page 17]

Internet-Draft              Crypto for TCP-AO               October 2009


   Eric Rescorla
   RTFM, Inc.
   2064 Edgewood Drive
   Palo Alto, CA  94303
   US

   Phone: 650-678-2350
   Email: ekr@rtfm.com











































Lebovitz & Rescorla      Expires April 29, 2010                [Page 18]



+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m
--=====================_37082250==.ALT-- From mallman@icir.org Tue Oct 27 07:30:31 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BD53A6832 for ; Tue, 27 Oct 2009 07:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ3hcFkzzgh8 for ; Tue, 27 Oct 2009 07:30:30 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 496733A6783 for ; Tue, 27 Oct 2009 07:30:30 -0700 (PDT) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n9REUVaT003937; Tue, 27 Oct 2009 07:30:31 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 50C563E0EFFA; Tue, 27 Oct 2009 10:30:26 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C6B8B55F005; Tue, 27 Oct 2009 10:30:25 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Blue on Black MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma1023-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 27 Oct 2009 10:30:25 -0400 Sender: mallman@icir.org Message-Id: <20091027143025.C6B8B55F005@lawyers.icir.org> Cc: k.avrachenkov@sophia.inria.fr, jblanton@cs.ohiou.edu Subject: [tcpm] early retransmit done? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 14:30:31 -0000 ----------ma1023-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline We believe we have addressed all comments we received on the early retranmsit ID. I just went to submit a new version and have missed the cut-off. I have set a bit to submit when the system opens again on Nov/9. However, until then I put the version I was going to submit here ... http://www.icir.org/mallman/papers/draft-ietf-tcpm-early-rexmt-02a.txt Comments are very welcome. allman ----------ma1023-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkrnBAEACgkQWyrrWs4yIs510QCfVPysDLXlnI16WNTYPfMAKaDv NlMAnRsHYFbqqfLJtf+q7yM84F+tEZNQ =mI1K -----END PGP SIGNATURE----- ----------ma1023-1-- From andrew.knutsen@bluecoat.com Tue Oct 27 12:25:22 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B63D3A69B5 for ; Tue, 27 Oct 2009 12:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb-YgN-aDZeN for ; Tue, 27 Oct 2009 12:25:21 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 84CF93A699C for ; Tue, 27 Oct 2009 12:25:21 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n9RJPZmf025495; Tue, 27 Oct 2009 12:25:36 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 12:25:31 -0700 Message-ID: <4AE7492B.9060405@bluecoat.com> Date: Tue, 27 Oct 2009 12:25:31 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Joe Touch References: <4AE65463.6020506@bluecoat.com> <4AE6888A.5080205@isi.edu> In-Reply-To: <4AE6888A.5080205@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2009 19:25:31.0651 (UTC) FILETIME=[3FAD9D30:01CA573B] Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 19:25:22 -0000 Joe Touch wrote: > Simply stating that simultaneous open isn't supported is insufficient. > The document needs to explain what happens when a SYN is received with > the option when in the SYN-SENT state - i.e., what happens in response > to the SYN received, and what happens if the other end responds to the > option in the SYN that has been sent. > > > Thats why the following text is there: 5.2. Initiating Discovery Request Requests are only valid in SYN packets. They MUST NOT appear in other segments and MUST be ignored when found outside of a SYN. 5.3. Responding to Discovery Request Requests received in any state except SYN-SENT MUST be ignored. Responses are only valid in valid SYN-ACK packets. They MUST NOT appear in other segments and MUST be ignored when found outside of a SYN-ACK. > > FWIW, the text in the security considerations needs to take space into > account as well Since the context of the connection impacts the space constraints, and that context depends on the device capability and changes over time, we feel these issues should be addressed in the specific capability specs. Several vendors are using various forms of this option (with invalid kind codes) without problems. If space problems arise, we will all have to change our formats, as mentioned in the spec. Perhaps if we adopt this draft, we can move away from the invalid codes at the same time. Andrew From touch@ISI.EDU Tue Oct 27 13:26:56 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1451B28C144 for ; Tue, 27 Oct 2009 13:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlzYtbtWdU97 for ; Tue, 27 Oct 2009 13:26:55 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 392573A69A0 for ; Tue, 27 Oct 2009 13:26:55 -0700 (PDT) Received: from [128.9.176.75] (c3-vpn4.isi.edu [128.9.176.75] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n9RKQKj4018161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 13:26:21 -0700 (PDT) Message-ID: <4AE7576B.2090407@isi.edu> Date: Tue, 27 Oct 2009 13:26:19 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andrew Knutsen References: <4AE65463.6020506@bluecoat.com> <4AE6888A.5080205@isi.edu> <4AE7492B.9060405@bluecoat.com> In-Reply-To: <4AE7492B.9060405@bluecoat.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig97C4B372C687BD9CA8F76401" X-MailScanner-ID: n9RKQKj4018161 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 20:26:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig97C4B372C687BD9CA8F76401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Knutsen wrote: > Joe Touch wrote: >> Simply stating that simultaneous open isn't supported is insufficient.= >> The document needs to explain what happens when a SYN is received with= >> the option when in the SYN-SENT state - i.e., what happens in response= >> to the SYN received, and what happens if the other end responds to the= >> option in the SYN that has been sent. >> >> >> =20 >=20 > Thats why the following text is there: >=20 > 5.2. Initiating Discovery Request >=20 > Requests are only valid in SYN packets. They MUST NOT appear in other= > segments and MUST be ignored when found outside of a SYN. Does that mean that the option is ignored, or the segment? > 5.3. Responding to Discovery Request >=20 > Requests received in any state except SYN-SENT MUST be ignored. >=20 > Responses are only valid in valid SYN-ACK packets. They MUST NOT > appear in other segments and MUST be ignored when found outside of a > SYN-ACK. AOK - so only the initiator of a connection can initiate this mechanism. >> FWIW, the text in the security considerations needs to take space into= >> account as well >=20 > Since the context of the connection impacts the space constraints, > and that context depends on the device capability and changes over time= , > we feel these issues should be addressed in the specific capability > specs. Several vendors are using various forms of this option (with > invalid kind codes) without problems. If space problems arise, we will > all have to change our formats, as mentioned in the spec. Perhaps if w= e > adopt this draft, we can move away from the invalid codes at the same t= ime. Space is less of an issue for connections not authenticated with TCP MD5 or TCP-AO. I agree that the details would be in the service capability specs. However, it's useful in the security considerations to explain the security impacts of the approach, i.e., basically: - use without TCP MD5 or TCP-AO which means it would require IPsec to be protected or - use when the extra information is basically null if this isn't expected to be the common case, then that's worth noting I.e., the security considerations should talk about what's expected, and what the limitations are in those cases. Joe --------------enig97C4B372C687BD9CA8F76401 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrnV2sACgkQE5f5cImnZrtGngCfS5+kTLnZL2isqZ+ITphKc1PY MJ0AoLCl1gWqFp9DKHEY8BqyUUCgma3e =RoAD -----END PGP SIGNATURE----- --------------enig97C4B372C687BD9CA8F76401-- From andrew.knutsen@bluecoat.com Tue Oct 27 14:09:32 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED50E28C131 for ; Tue, 27 Oct 2009 14:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXOl2cUJFAXh for ; Tue, 27 Oct 2009 14:09:32 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 7D54A3A67ED for ; Tue, 27 Oct 2009 14:09:31 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n9RL9jHK017661; Tue, 27 Oct 2009 14:09:45 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 14:09:40 -0700 Message-ID: <4AE76194.90404@bluecoat.com> Date: Tue, 27 Oct 2009 14:09:40 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Joe Touch References: <4AE65463.6020506@bluecoat.com> <4AE6888A.5080205@isi.edu> <4AE7492B.9060405@bluecoat.com> <4AE7576B.2090407@isi.edu> In-Reply-To: <4AE7576B.2090407@isi.edu> Content-Type: multipart/alternative; boundary="------------050204010606090100080703" X-OriginalArrivalTime: 27 Oct 2009 21:09:40.0518 (UTC) FILETIME=[CC4B0C60:01CA5749] Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 21:09:33 -0000 This is a multi-part message in MIME format. --------------050204010606090100080703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joe Touch wrote: > Andrew Knutsen wrote: > >> Requests are only valid in SYN packets. They MUST NOT appear in other >> segments and MUST be ignored when found outside of a SYN. >> > > Does that mean that the option is ignored, or the segment? > I think the concept of ignoring options is pretty well understood, but perhaps we can add a reference. This situation is slightly unusual, since TCP options, in the "classic" Internet model, are always ignored by intermediate nodes (no "deep inspection"). This is no longer the case though, so the semantics of "ignoring" IP options apply to TCP options (pass them along intact at intermediates), as well as the usual interpretation of ignoring a TCP option (skip over them at the endpoint). This is well established "art", so we didn't see the necessity of explanation... > Space is less of an issue for connections not authenticated with TCP MD5 > or TCP-AO. I agree that the details would be in the service capability > specs. However, it's useful in the security considerations to explain > the security impacts of the approach, i.e., basically: > > - use without TCP MD5 or TCP-AO > which means it would require IPsec to be protected > or > > - use when the extra information is basically null > if this isn't expected to be the common case, then > that's worth noting > > I.e., the security considerations should talk about what's expected, and > what the limitations are in those cases. > > First, I'll note again that protection would not require MD5, AO or IPSec, if a hash is included in the target data. Regarding uses, whats expected is that the option will be used primarily for its current use (although if it has other uses thats great). In this case, which is a compression tunnel, the only time we'd have to deal with both options is if the client sent the MD5/AO, and policy said we should pass it to the server. This is the case described in the "Interoperability" section, since it applies to other large client-originated options as well. In the "slow path", if the connection is in fact intercepted, there is a bit more handshake during tunnel setup to use for auth -- so MD5/AO is not necessary between the tunnel endpoints. Again, these details would depend on the specific device capability. Andrew --------------050204010606090100080703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Joe Touch wrote: 
Andrew Knutsen wrote:
  
  Requests are only valid in SYN packets. They MUST NOT appear in other
  segments and MUST be ignored when found outside of a SYN.
    

Does that mean that the option is ignored, or the segment?

        I think the concept of ignoring options is pretty well understood, but perhaps we can add a reference. This situation is slightly unusual, since TCP options, in the "classic" Internet model, are always ignored by intermediate nodes (no "deep inspection"). This is no longer the case though, so the semantics of "ignoring" IP options apply to TCP options (pass them along intact at intermediates), as well as the usual interpretation of ignoring a TCP option (skip over them at the endpoint). This is well established "art", so we didn't see the necessity of explanation...

Space is less of an issue for connections not authenticated with TCP MD5
or TCP-AO. I agree that the details would be in the service capability
specs. However, it's useful in the security considerations to explain
the security impacts of the approach, i.e., basically:

	- use without TCP MD5 or TCP-AO
	which means it would require IPsec to be protected
or

	- use when the extra information is basically null
	if this isn't expected to be the common case, then
	that's worth noting

I.e., the security considerations should talk about what's expected, and
what the limitations are in those cases.

    First, I'll note again that protection would not require MD5, AO or IPSec, if a hash is included in the target data.

    Regarding uses, whats expected is that the option will be used primarily for its current use (although if it has other uses thats great).  In this case, which is a compression tunnel, the only time we'd have to deal with both options is if the client sent the MD5/AO, and policy said we should pass it to the server. This is the case described in the "Interoperability" section, since it applies to other large client-originated options as well.

    In the "slow path", if the connection is in fact intercepted, there is a bit more handshake during tunnel setup to use for auth -- so MD5/AO is not necessary between the tunnel endpoints. Again, these details would depend on the specific device capability.

Andrew

--------------050204010606090100080703-- From touch@ISI.EDU Tue Oct 27 15:59:11 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E5D3A6856 for ; Tue, 27 Oct 2009 15:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yicvq+4RHfJS for ; Tue, 27 Oct 2009 15:59:11 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 1D2673A6851 for ; Tue, 27 Oct 2009 15:59:11 -0700 (PDT) Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n9RMw7n0022762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 15:58:08 -0700 (PDT) Message-ID: <4AE77AFF.6000700@isi.edu> Date: Tue, 27 Oct 2009 15:58:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andrew Knutsen References: <4AE65463.6020506@bluecoat.com> <4AE6888A.5080205@isi.edu> <4AE7492B.9060405@bluecoat.com> <4AE7576B.2090407@isi.edu> <4AE76194.90404@bluecoat.com> In-Reply-To: <4AE76194.90404@bluecoat.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3241940B85E8FDF1AA323256" X-MailScanner-ID: n9RMw7n0022762 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh Subject: Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:59:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3241940B85E8FDF1AA323256 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Knutsen wrote: > Joe Touch wrote: >> Andrew Knutsen wrote: >> =20 >>> Requests are only valid in SYN packets. They MUST NOT appear in oth= er >>> segments and MUST be ignored when found outside of a SYN. >>> =20 >> >> Does that mean that the option is ignored, or the segment? >> =20 >=20 > I think the concept of ignoring options is pretty well > understood, but perhaps we can add a reference. This situation is > slightly unusual, since TCP options, in the "classic" Internet model, > are always ignored by intermediate nodes (no "deep inspection"). This i= s > no longer the case though, so the semantics of "ignoring" IP options > apply to TCP options (pass them along intact at intermediates), as well= > as the usual interpretation of ignoring a TCP option (skip over them at= > the endpoint). This is well established "art", so we didn't see the > necessity of explanation... It's not at all clear to me that the text makes it clear that this protocol involves the participation of intermediate nodes. You're going to need a lot more explanation of how that is expected to be handled, esp. since intermediate nodes don't keep TCP states. E.g.: you need to explain what intermediate nodes do for each message, and whether they need to keep state (and if so, how it is established and maintained). You also need clear indication about what the endpoints do with these messages if they ever see them (are they stripped off, or still there?). Joe --------------enig3241940B85E8FDF1AA323256 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrnev8ACgkQE5f5cImnZruA0QCgwXXYMfvXbIs9tGIGyfIfCFXe D0IAmwfirUzSCoskr7KZyPKBKYELsHzF =/4jp -----END PGP SIGNATURE----- --------------enig3241940B85E8FDF1AA323256-- From gregory.ietf@gmail.com Wed Oct 28 07:03:08 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B1B3A693A for ; Wed, 28 Oct 2009 07:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzhPFpmnAmOG for ; Wed, 28 Oct 2009 07:03:07 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id F06BE3A6782 for ; Wed, 28 Oct 2009 07:03:05 -0700 (PDT) Received: by bwz23 with SMTP id 23so1033126bwz.29 for ; Wed, 28 Oct 2009 07:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=Laxj6Zj1VzrzW7gc4TOFTIRYyCpau7NZd/+kFP+cUtY=; b=hoVX33C0G4eEskZuhXEnJnVDjdWDcKcroD4ztXHbl+R6wAwbNWH6kMZDSCu8pEaVLr EjOQ1il7lmQtcq/eZCFhU6pa/NzGfDdsdQPIns1KpabsNAWhda3Qhm8iT0Yfo3K420Z8 y5if213WSsKVIU9dHgKwNQe1D7A6AGNipqJq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=Ef2ZuzmDFE0xKsJS3sd/uwMW+D8rVokoy1YDKbefa1r9wu6vYkqtjv647+JPRQdVMP EV6sPke0PiVJpokUy91OQYYzH6IeQBZbSDdo8k/IsUKOoOSOGDIJo+WqGeUWHBRveI5C LSNl+9/Xdcea+WegBifV+I8SaoIYSfvrPcSB8= Received: by 10.204.33.194 with SMTP id i2mr851335bkd.146.1256738597647; Wed, 28 Oct 2009 07:03:17 -0700 (PDT) Received: from Gregory-T60.gmail.com (c-98-248-97-91.hsd1.ca.comcast.net [98.248.97.91]) by mx.google.com with ESMTPS id c28sm1749967fka.54.2009.10.28.07.03.14 (version=SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 07:03:17 -0700 (PDT) Message-ID: <4ae84f25.1c365e0a.0732.ffff9e86@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 28 Oct 2009 07:03:01 -0700 To: Lars Eggert ,Joe Touch From: "Gregory M. Lebovitz" In-Reply-To: <7.1.0.9.2.20091028061224.04f0b630@gmail.com> References: <4ae65741.9513f30a.2317.45e5@mx.google.com> <4AE68EF5.9090100@isi.edu> <4AE71454.6080405@isi.edu> <4AE71E9D.9050109@isi.edu> <4AE73694.8060701@isi.edu> <4AE7DF1D.5060304@isi.edu> <7C435725-BB1A-446A-884D-05A28AE312C2@nokia.com> <7.1.0.9.2.20091028061224.04f0b630@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_124683750==_" Cc: "tcpm-chairs@tools.ietf.org" , Eric Rescorla , tcpm@ietf.org Subject: [tcpm] draft-ietf-tcpm-tcp-ao-crypto-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:03:08 -0000 --=====================_124683750==_ Content-Type: multipart/alternative; boundary="=====================_124683750==.ALT" --=====================_124683750==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Attached is ...ao-crypto-02, as requested. It has the following changes: - added changes to log for -01 & -02 - s/KDF_algo/KDF_alg , in order to match what I saw in auth-opt-08 - s/MAC_algo/MAC_alg, to match auth-opt-08 - in 3.1, change to definition of "Context" to simply refer to -auth-opt-08, now that it uses the word "Context" it will be straightforward. - in 3.1.1.1 & 3.1.1.2, s/PRF:/PRF for KDF_alg: for clarification I will manually submit the .xml and .txt to internet-drafts@ietf.org, and trust Lars will do his magic to get it published. If there are any other issues, may we please address them during WG LC, as I have exceeded my time budget for this document already, and need to get other IETF docs and work? See you at the Bar BoF in Hiroshima (or on list ;-)! Gregory. At 06:19 AM 10/28/2009, Gregory M. Lebovitz wrote: >At 12:06 AM 10/28/2009, Lars Eggert wrote: >>Hi, >> >>On 2009-10-28, at 8:05, Joe Touch wrote: >>>Gregory Lebovitz wrote: --snip-- >>right, I thought that there was a correction to the "context" >>definition that was desired? > >Ok, I'll make that change, rebuild and send as -02. > >Looked for you on IM, but you were offline. ... > >re: submitting "manually": after Joe sent you his version, you told >Joe you wanted "manual" submission. I assume that you mean, >according to >"http://www.ietf.org/id-info/guidelines.html" >sect 1 "If you run into problems when submitting an Internet-Draft >using the I-D Submission tool, or it is not available or you are >offline, you may alternatively submit your draft by email to >internet-drafts@ietf.org," correct? I would otherwise assume this >would get denied automatically, due to being past deadline, but if >that's what you want, I'll concur. > >Pls advise, >Gregory. > > >>Lars --=====================_124683750==.ALT Content-Type: text/html; charset="us-ascii" Attached is ...ao-crypto-02, as requested. It has the following changes:
 - added changes to log for -01 & -02
 - s/KDF_algo/KDF_alg , in order to match what I saw in auth-opt-08
 - s/MAC_algo/MAC_alg, to match auth-opt-08
 - in 3.1, change to definition of "Context" to simply refer to -auth-opt-08, now that it uses the word "Context" it will be straightforward.
 - in 3.1.1.1 & 3.1.1.2, s/PRF:/PRF for KDF_alg:   for clarification

I will manually submit the .xml and .txt to internet-drafts@ietf.org, and trust Lars will do his magic to get it published.

If there are any other issues, may we please address them during WG LC, as I have exceeded my time budget for this document already, and need to get other IETF docs and work? See you at the Bar BoF in Hiroshima (or on list ;-)!

Gregory.

At 06:19 AM 10/28/2009, Gregory M. Lebovitz wrote:
At 12:06 AM 10/28/2009, Lars Eggert wrote:
Hi,

On 2009-10-28, at 8:05, Joe Touch wrote:
Gregory Lebovitz wrote:

--snip--


right, I thought that there was a correction to the "context" 
definition that was desired?

Ok, I'll make that change, rebuild and send as -02.

Looked for you on IM, but you were offline. ...

re: submitting "manually":  after Joe sent you his version, you told Joe you wanted "manual" submission. I assume that you mean, according to " http://www.ietf.org/id-info/guidelines.html" sect 1 "If you run into problems when submitting an Internet-Draft using the I-D Submission tool, or it is not available or you are offline, you may alternatively submit your draft by email to internet-drafts@ietf.org," correct? I would otherwise assume this would get denied automatically, due to being past deadline, but if that's what you want, I'll concur.

Pls advise,
Gregory.


Lars
--=====================_124683750==.ALT-- --=====================_124683750==_ Content-Type: application/octet-stream; name="draft-ietf-tcpm-tcp-ao-crypto-02.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-tcpm-tcp-ao-crypto-02.txt" CgoKVENQTSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEcuIExlYm92aXR6CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVuaXBlcgpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRS4gUmVzY29ybGEKRXhwaXJl czogTWF5IDEsIDIwMTAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBSVEZNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgT2N0b2JlciAyOCwgMjAwOQoKCiAgICBDcnlwdG9ncmFwaGljIEFsZ29yaXRobXMg Zm9yIFRDUCdzIEF1dGhlbnRpY2F0aW9uIE9wdGlvbiwgVENQLUFPCiAgICAgICAgICAgICAgICAg ICAgZHJhZnQtaWV0Zi10Y3BtLXRjcC1hby1jcnlwdG8tMDEKClN0YXR1cyBvZiB0aGlzIE1lbW8K CiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIHRvIElFVEYgaW4gZnVsbCBjb25m b3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LiAgVGhp cyBkb2N1bWVudCBtYXkgY29udGFpbiBtYXRlcmlhbAogICBmcm9tIElFVEYgRG9jdW1lbnRzIG9y IElFVEYgQ29udHJpYnV0aW9ucyBwdWJsaXNoZWQgb3IgbWFkZSBwdWJsaWNseQogICBhdmFpbGFi bGUgYmVmb3JlIE5vdmVtYmVyIDEwLCAyMDA4LiAgVGhlIHBlcnNvbihzKSBjb250cm9sbGluZyB0 aGUKICAgY29weXJpZ2h0IGluIHNvbWUgb2YgdGhpcyBtYXRlcmlhbCBtYXkgbm90IGhhdmUgZ3Jh bnRlZCB0aGUgSUVURgogICBUcnVzdCB0aGUgcmlnaHQgdG8gYWxsb3cgbW9kaWZpY2F0aW9ucyBv ZiBzdWNoIG1hdGVyaWFsIG91dHNpZGUgdGhlCiAgIElFVEYgU3RhbmRhcmRzIFByb2Nlc3MuICBX aXRob3V0IG9idGFpbmluZyBhbiBhZGVxdWF0ZSBsaWNlbnNlIGZyb20KICAgdGhlIHBlcnNvbihz KSBjb250cm9sbGluZyB0aGUgY29weXJpZ2h0IGluIHN1Y2ggbWF0ZXJpYWxzLCB0aGlzCiAgIGRv Y3VtZW50IG1heSBub3QgYmUgbW9kaWZpZWQgb3V0c2lkZSB0aGUgSUVURiBTdGFuZGFyZHMgUHJv Y2VzcywgYW5kCiAgIGRlcml2YXRpdmUgd29ya3Mgb2YgaXQgbWF5IG5vdCBiZSBjcmVhdGVkIG91 dHNpZGUgdGhlIElFVEYgU3RhbmRhcmRzCiAgIFByb2Nlc3MsIGV4Y2VwdCB0byBmb3JtYXQgaXQg Zm9yIHB1YmxpY2F0aW9uIGFzIGFuIFJGQyBvciB0bwogICB0cmFuc2xhdGUgaXQgaW50byBsYW5n dWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVU RiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdAogICBvdGhl ciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5l dC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFs aWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVw bGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJ dCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAg IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiIKCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3Nl ZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuCgogICBU aGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vz c2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgogICBUaGlzIEludGVy bmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1heSAxLCAyMDEwLgoKQ29weXJpZ2h0IE5vdGljZQoK ICAgQ29weXJpZ2h0IChjKSAyMDA5IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZp ZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKCgoK TGVib3ZpdHogJiBSZXNjb3JsYSAgICAgICAgRXhwaXJlcyBNYXkgMSwgMjAxMCAgICAgICAgICAg ICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENyeXB0byBmb3Ig VENQLUFPICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKICAgVGhpcyBkb2N1bWVudCBpcyBz dWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNpb25z IFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBw dWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNl bnNlLWluZm8pLgogICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cyBjYXJlZnVsbHksIGFz IHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMKICAgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3Bl Y3QgdG8gdGhpcyBkb2N1bWVudC4KCkFic3RyYWN0CgogICBUaGUgVENQIEF1dGhlbnRpY2F0aW9u IE9wdGlvbiwgVENQLUFPLCByZWxpZXMgb24gc2VjdXJpdHkgYWxnb3JpdGhtcwogICB0byBwcm92 aWRlIGF1dGhlbnRpY2F0aW9uIGJldHdlZW4gdHdvIGVuZC1wb2ludHMuICBUaGVyZSBhcmUgbWFu eQogICBzdWNoIGFsZ29yaXRobXMgYXZhaWxhYmxlLCBhbmQgdHdvIFRDUC1BTyBzeXN0ZW1zIGNh bm5vdCBpbnRlcm9wZXJhdGUKICAgdW5sZXNzIHRoZXkgYXJlIHVzaW5nIHRoZSBzYW1lIGFsZ29y aXRobShzKS4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzCiAgIHRoZSBhbGdvcml0aG1zIGFuZCBh dHRyaWJ1dGVzIHRoYXQgY2FuIGJlIHVzZWQgaW4gVENQLUFPJ3MgY3VycmVudAogICBtYW51YWwg a2V5aW5nIG1lY2hhbmlzbS4KCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlv biAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAg IDIuICBSZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMwogICAgIDIuMS4gIFJlcXVpcmVtZW50cyBMYW5ndWFnZSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAgICAyLjIuICBBbGdvcml0aG0gUmVxdWly ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgICAgMi4zLiAg UmVxdWlyZW1lbnRzIGZvciBGdXR1cmUgTUFDIEFsZ29yaXRobXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAgNAogICAzLiAgQWxnb3JpdGhtcyBTcGVjaWZpZWQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICAzLjEuICBLZXkgRGVyaXZhdGlvbiBGdW5jdGlvbnMg KEtERnMpICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgICAzLjEuMS4gIENvbmNy ZXRlIEtERnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAg IDMuMi4gIE1BQyBBbGdvcml0aG1zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTAKICAgICAgIDMuMi4xLiAgVGhlIFVzZSBvZiBITUFDLVNIQS0xLTk2IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgICAzLjIuMi4gIFRoZSBVc2Ugb2YgQUVT LTEyOC1DTUFDLTk2IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICA0LiAgQ2hhbmdl IEhpc3RvcnkgKFJGQyBFZGl0b3I6IERlbGV0ZSBiZWZvcmUgcHVibGlzaGluZykgIC4gLiAuIC4g MTIKICAgNS4gIE5lZWRzIFdvcmsgaW4gTmV4dCBEcmFmdCAoUkZDIEVkaXRvcjogRGVsZXRlIEJl Zm9yZQogICAgICAgUHVibGlzaGluZykgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTQKICAgNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0CiAgIDcuICBJQU5BIENvbnNpZGVy YXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQogICA4 LiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTUKICAgOS4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgICAgOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5j ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAgIDkuMi4gIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTYKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE3CgoKCgoKCgoKCgoKCkxlYm92aXR6ICYgUmVzY29ybGEgICAgICAg IEV4cGlyZXMgTWF5IDEsIDIwMTAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBDcnlwdG8gZm9yIFRDUC1BTyAgICAgICAgICAgICAgIE9jdG9i ZXIgMjAwOQoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFRoaXMgZG9jdW1lbnQgaXMgYSBjb21wYW5p b24gdG8gVENQLUFPIFtUQ1AtQU9dCiAgIFtJLUQuaWV0Zi10Y3BtLXRjcC1hdXRoLW9wdF0uICBM aWtlIG1vc3QgbW9kZXJuIHNlY3VyaXR5IHByb3RvY29scywKICAgVENQLUFPIGFsbG93cyB1c2Vy cyB0byBjaG9zZSB3aGljaCBjcnlwdG9ncmFwaGljIGFsZ29yaXRobShzKSB0aGV5CiAgIHdhbnQg dG8gdXNlIHRvIG1lZXQgdGhlaXIgc2VjdXJpdHkgbmVlZHMuCgogICBUQ1AtQU8gcHJvdmlkZXMg Y3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNhdGlvbiBhbmQgbWVzc2FnZSBpbnRlZ3JpdHkKICAgdmVy aWZpY2F0aW9uIGJldHdlZW4gdG8gZW5kLXBvaW50cy4gIEluIG9yZGVyIHRvIGFjY29tcGxpc2gg dGhpcwogICBmdW5jdGlvbiwgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlcyAoTUFDcykgYXJl IHVzZWQsIHdoaWNoIHRoZW4KICAgcmVseSBvbiBzaGFyZWQga2V5cy4gIFRoZXJlIGFyZSB2YXJp b3VzIHdheXMgdG8gY3JlYXRlIE1BQ3MuICBUaGUgdXNlCiAgIG9mIGhhc2hlZC1iYXNlZCBNQUNz IChITUFDKSBpbiBJbnRlcm5ldCBwcm90b2NvbHMgaXMgZGVmaW5lZCBpbgogICBbUkZDMjEwNF0u ICBUaGUgdXNlIG9mIGNpcGhlci1iYXNlZCBNQUNzIChDTUFDKSBpbiBJbnRlcm5ldCBwcm90b2Nv bHMKICAgaXMgZGVmaW5lZCBpbiBbUkZDNDQ5M10uCgogICBUaGlzIFJGQyBkZWZpbmVzIHRoZSBn ZW5lcmFsIHJlcXVpcmVtZW50cyBmb3IgTUFDcyB1c2VkIGluIFRDUC1BTywKICAgYm90aCBmb3Ig Y3VycmVudGx5IHNwZWNpZmllZCBNQUNzIGFuZCBmb3IgYW55IGZ1dHVyZSBzcGVjaWZpZWQgTUFD cy4KICAgSXQgdGhlbiBzcGVjaWZpZXMgdHdvIE1BQyBhbGdvcml0aG1zIHJlcXVpcmVkIGluIGFs bCBUQ1AtQU8KICAgaW1wbGVtZW50YXRpb25zLiAgSXQgYWxzbyBzcGVjaWZpZXMgdHdvIGtleSBk ZXJpdmF0aW9ucyBmdW5jdGlvbnMKICAgKEtERnMpIHVzZWQgdG8gY3JlYXRlIHRoZSB0cmFmZmlj IGtleXMgdXNlZCBieSB0aGUgTUFDcy4gIFRoZXNlIEtERnMKICAgYXJlIGFsc28gcmVxdWlyZWQg YnkgYWxsIFRDUC1BTyBpbXBsZW1lbnRhdGlvbnMuCgoKMi4gIFJlcXVpcmVtZW50cwoKMi4xLiAg UmVxdWlyZW1lbnRzIExhbmd1YWdlCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9U IiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxE IE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRv Y3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoK ICAgV2hlbiB1c2VkIGluIGxvd2VyIGNhc2UsIHRoZXNlIHdvcmRzIGNvbnZleSB0aGVpciB0eXBp Y2FsIHVzZSBpbgogICBjb21tb24gbGFuZ3VhZ2UsIGFuZCBhcmUgbm90IHRvIGJlIGludGVycHJl dGVkIGFzIGRlc2NyaWJlZCBpbgogICBbUkZDMjExOV0uCgoyLjIuICBBbGdvcml0aG0gUmVxdWly ZW1lbnRzCgogICBUaGlzIGlzIHRoZSBpbml0aWFsIHNwZWNpZmljYXRpb24gb2YgcmVxdWlyZWQg Y3J5cHRvZ3JhcGh5IGZvcgogICBUQ1AtQU8sIGFuZCBpbmRpY2F0ZXMgdHdvIE1BQyBhbGdvcml0 aG1zIGFuZCB0d28gS0RGcy4gIEFsbCBmb3VyCiAgIGNvbXBvbmVudHMgTVVTVCBiZSBpbXBsZW1l bnRlZCBpbiBvcmRlciBmb3IgdGhlIGltcGxlbWVudGF0aW9uIHRvIGJlCiAgIGZ1bGx5IGNvbXBs aWFudCB3aXRoIHRoaXMgUkZDLgoKICAgVGhlIGZvbGxvd2luZyB0YWJsZSBpbmRpY2F0ZXMgdGhl IHJlcXVpcmVkIE1BQyBhbGdvcml0aG1zIGFuZCBLREZzCiAgIGZvciBUQ1AtQU86CgoKCgoKCgpM ZWJvdml0eiAmIFJlc2NvcmxhICAgICAgICBFeHBpcmVzIE1heSAxLCAyMDEwICAgICAgICAgICAg ICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQ3J5cHRvIGZvciBU Q1AtQU8gICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgogICAgICAgICAgIFJlcXVpcmVtZW50 ICAgICAgQXV0aGVudGljYXRpb24gQWxnb3JpdGhtCiAgICAgICAgICAgLS0tLS0tLS0tLS0tICAg ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgICAgICAgICBNVVNUICAgICAgICAgICAgIEhN QUMtU0hBLTEtOTYgW1JGQzI0MDRdCiAgICAgICAgICAgTVVTVCAgICAgICAgICAgICBBRVMtMTI4 LUNNQUMtOTYgW1JGQzQ0OTNdCgogICAgICAgICAgIFJlcXVpcmVtZW50ICAgICAgS2V5IERlcml2 YXRpb24gRnVuY3Rpb24gKEtERikKICAgICAgICAgICAtLS0tLS0tLS0tLS0tICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQogICAgICAgICAgIE1VU1QgICAgICAgICAgICAgS0RGX0hNQUNfU0hB MQogICAgICAgICAgIE1VU1QgICAgICAgICAgICAgS0RGX0FFU18xMjhfQ01BQwoKICAgTk9URSBF WFBMQUlOSU5HIFdIWSBUV08gTUFDIEFMR09SSVRITVMgV0VSRSBNQU5EQVRFRDoKCiAgIFR3byBN QUMgYWxnb3JpdGhtcyBhbmQgdHdvIGNvcnJlc3BvbmRpbmcgS0RGcyBhcmUgbWFuZGF0ZWQgYXMg YQogICByZXN1bHQgb2YgZGlzY3Vzc2lvbiBpbiB0aGUgVENQTSBXRywgYW5kIGluIGNvbnN1bHRh dGlvbiB3aXRoIHRoZQogICBTZWN1cml0eSBBcmVhIERpcmVjdG9ycy4gIFNIQS0xIHdhcyBzZWxl Y3RlZCBiZWNhdXNlIGl0IGlzIHdpZGVseQogICBkZXBsb3llZCBhbmQgY3VycmVudGx5IGhhcyBz dWZmaWNpZW50IHN0cmVuZ3RoIGFuZCByZWFzb25hYmxlCiAgIGNvbXB1dGF0aW9uYWwgY29zdCwg c28gaXQgaXMgYSAiTVVTVCIgZm9yIFRDUC1BTyB0b2RheS4gIFRoZSBzZWN1cml0eQogICBzdHJl bmd0aCBvZiBTSEEtMSBITUFDcyBzaG91bGQgYmUgc3VmZmljaWVudCBmb3IgdGhlIGZvcmVzZWVh YmxlCiAgIGZ1dHVyZSwgZXNwZWNpYWxseSBnaXZlbiB0aGF0IHRoZSB0YWdzIGFyZSB0cnVuY2F0 ZWQgdG8gOTYgYml0cy4KCiAgIFJlY2VudGx5IGV4cG9zZWQgdnVsbmVyYWJpbGl0aWVzIGluIG90 aGVyIE1BQ3MgKGUuZy4sIE1ENSBvciBITUFDCiAgIE1ENSkgYXJlbid0IHByYWN0aWNhbCBvbiBT SEEtMSwgYnV0IHRoZXNlIHR5cGVzIG9mIGFuYWx5c2VzIGFyZQogICBtb3VudGluZyBhbmQgY291 bGQgcG90ZW50aWFsbHkgcG9zZSBhIGNvbmNlcm4gZm9yIEhNQUMgZm9yZ2VyeSBpZgogICB0aGV5 IHdlcmUgc2lnbmlmaWNhbnRseSBpbXByb3ZlZCwgb3ZlciB0aW1lLiAgVGhlIHNlY3VyaXR5IGlz c3VlcwogICBkcml2aW5nIHRoZSBtaWdyYXRpb24gZnJvbSBTSEEtMSB0byBTSEEtMjU2IGZvciBk aWdpdGFsIHNpZ25hdHVyZXMKICAgW0hNQUMtQVRUQUNLXSBkbyBub3QgaW1tZWRpYXRlbHkgcmVu ZGVyIFNIQS0xIHdlYWsgZm9yIHRoaXMKICAgYXBwbGljYXRpb24gb2YgU0hBLTEgaW4gSE1BQyBt b2RlLgoKICAgQUVTLTEyOCBDTUFDIGlzIGNvbnNpZGVyZWQgdG8gYmUgYSBzdHJvbmdlciBhbGdv cml0aG0gdGhhbiBTSEEtMSwgYnV0CiAgIG1heSBub3QgeWV0IGhhdmUgdmVyeSB3aWRlIGltcGxl bWVudGF0aW9uLiAgQUVTLTEyOCBDTUFDIGlzIGFsc28gYQogICAiTVVTVCIgdG8gaW1wbGVtZW50 LCBpbiBvcmRlciB0byBkcml2ZSB2ZW5kb3JzIHRvd2FyZCBpdHMgdXNlLCBhbmQgdG8KICAgYWxs b3cgZm9yIGFub3RoZXIgTUFDIG9wdGlvbiwgaWYgU0hBLTEgd2VyZSB0byBiZSBjb21wcm9taXNl ZC4KCjIuMy4gIFJlcXVpcmVtZW50cyBmb3IgRnV0dXJlIE1BQyBBbGdvcml0aG1zCgogICBUQ1At QU8gaXMgaW50ZW5kZWQgdG8gc3VwcG9ydCBjcnlwdG9ncmFwaGljIGFnaWxpdHkuICBBcyBhIHJl c3VsdCwKICAgdGhpcyBkb2N1bWVudCBpbmNsdWRlcyByZWNvbW1lbmRhdGlvbnMgaW4gdmFyaW91 cyBwbGFjZXMgZm9yIGZ1dHVyZQogICBNQUMgYW5kIEtERiBhbGdvcml0aG1zIHdoZW4gdXNlZCBm b3IgVENQLUFPLiAgRm9yIGZ1dHVyZSBNQUMKICAgYWxnb3JpdGhtcyBzcGVjaWZpY2FsbHksIHRo ZXkgU0hPVUxEIHByb3RlY3QgYXQgbGVhc3QgMioqNDggbWVzc2FnZXMKICAgd2l0aCBhIGNvbGxp c2lvbiBwcm9iYWJpbGl0eSBvZiBsZXNzIHRoYW4gb25lIGluIDEwKio5LgoKICAgW1Jldmlld2Vy czogQXJlIHRoZXJlIGFueSBvdGhlciByZXF1aXJlbWVudHMgd2Ugd2FudC9uZWVkIHRvIHBsYWNl IGluCiAgIGhlcmU/ICBSRkMgRURJVE9SOiBQbGVhc2UgZGVsZXRlIHRoaXMgbm90ZSBiZWZvcmUg cHVibGlzaGluZyBhcyBSRkNdCgoKMy4gIEFsZ29yaXRobXMgU3BlY2lmaWVkCgogICBUQ1AtQU8g cmVxdWlyZXMgdHdvIGNsYXNzZXMgb2YgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zIHVzZWQgb24g YQoKCgpMZWJvdml0eiAmIFJlc2NvcmxhICAgICAgICBFeHBpcmVzIE1heSAxLCAyMDEwICAgICAg ICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQ3J5cHRv IGZvciBUQ1AtQU8gICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgogICBwYXJ0aWN1bGFyIGNv bm5lY3Rpb24sIGFuZCByZWZlcnMgdG8gdGhpcyBkb2N1bWVudCB0byBkZWZpbmUgdGhlbQogICBi b3RoOgoKCiAgICAgICAoMSkgIEtleSBEZXJpdmF0aW9uIEZ1bmN0aW9ucyAoS0RGcykgd2hpY2gg bmFtZSBhIHBzZXVkb3JhbmRvbQogICAgICAgICAgICBmdW5jdGlvbiAoUFJGKSBhbmQgdXNlIGEg TWFzdGVyX0tleSBhbmQgc29tZSBjb25uZWN0aW9uLQogICAgICAgICAgICBzcGVjaWZpYyBpbnB1 dCB3aXRoIHRoYXQgUFJGIHRvIHByb2R1Y2UgVHJhZmZpY19LZXlzLCB0aGUKICAgICAgICAgICAg a2V5cyBzdWl0YWJsZSBmb3IgYXV0aGVudGljYXRpbmcgYW5kIGludGVncml0eSBjaGVja2luZwog ICAgICAgICAgICBpbmRpdmlkdWFsIFRDUCBzZWdtZW50cywgYXMgZGVzY3JpYmVkIGluIFRDUC1B Ty4KICAgICAgICgyKSAgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiBDb2RlIChNQUMpIGFsZ29yaXRo bXMgd2hpY2ggdGFrZSBhCiAgICAgICAgICAgIGtleSBhbmQgYSBtZXNzYWdlIGFuZCBwcm9kdWNl IGFuIGF1dGhlbnRpY2F0aW9uIHRhZyB3aGljaAogICAgICAgICAgICBjYW4gYmUgdXNlZCB0byB2 ZXJpZnkgdGhlIGludGVncml0eSBhbmQgYXV0aGVudGljaXR5IG9mCiAgICAgICAgICAgIHRob3Nl IG1lc3NhZ2VzLgoKICAgSW4gVENQLUFPLCB0aGVzZSBhbGdvcml0aG1zIGFyZSBhbHdheXMgdXNl ZCBpbiBwYWlycy4gIEVhY2ggTUFDCiAgIGFsZ29yaXRobSBNVVNUIHNwZWNpZnkgdGhlIEtERiB0 byBiZSB1c2VkIHdpdGggdGhhdCBNQUMgYWxnb3JpdGhtLgogICBIb3dldmVyLCBhIEtERiBNQVkg YmUgdXNlZCB3aXRoIG1vcmUgdGhhbiBvbmUgTUFDIGFsZ29yaXRobS4KCjMuMS4gIEtleSBEZXJp dmF0aW9uIEZ1bmN0aW9ucyAoS0RGcykKCiAgIFRDUC1BTydzIFRyYWZmaWNfS2V5cyBhcmUgZGVy aXZlZCB1c2luZyBLREZzLiAgVGhlIEtERnMgdXNlZCBpbiBUQ1AtCiAgIEFPJ3MgY3VycmVudCBt YW51YWwga2V5aW5nIGhhdmUgdGhlIGZvbGxvd2luZyBpbnRlcmZhY2U6CgogICAgICAgVHJhZmZp Y19LZXkgPSBLREZfYWxnKE1hc3Rlcl9LZXksIENvbnRleHQsIE91dHB1dF9MZW5ndGgpCgogICB3 aGVyZToKCgogICAgICAtIEtERl9hbGc6ICAgICB0aGUgc3BlY2lmaWMgcHNldWRvcmFuZG9tIGZ1 bmN0aW9uIChQUkYpIHRoYXQgaXMKICAgICAgICAgICAgICAgICAgICAgdGhlIGJhc2ljIGJ1aWxk aW5nIGJsb2NrIHVzZWQgaW4gY29uc3RydWN0aW5nIHRoZQogICAgICAgICAgICAgICAgICAgICBn aXZlbiBUcmFmZmljX0tleS4KCiAgICAgIC0gTWFzdGVyX0tleTogIEluIFRDUC1BTydzIG1hbnVh bCBrZXkgbW9kZSwgdGhpcyBpcyBhIGtleSBzaGFyZWQKICAgICAgICAgICAgICAgICAgICAgYnkg Ym90aCBwZWVycywgZW50ZXJlZCB2aWEgc29tZSBpbnRlcmZhY2UgdG8gdGhlaXIKICAgICAgICAg ICAgICAgICAgICAgcmVzcGVjdGl2ZSBjb25maWd1cmF0aW9ucy4gIFRoZSBNYXN0ZXJfS2V5IGlz IHVzZWQKICAgICAgICAgICAgICAgICAgICAgYXMgdGhlIHNlZWQgZm9yIHRoZSBLREYuICBXZSBh c3N1bWUgdGhhdCB0aGlzIGlzIGEKICAgICAgICAgICAgICAgICAgICAgaHVtYW4tcmVhZGFibGUg cHJlLXNoYXJlZCBrZXkgKFBTSyksIHRodXMgd2UgYXNzdW1lCiAgICAgICAgICAgICAgICAgICAg IGl0IGlzIG9mIHZhcmlhYmxlIGxlbmd0aC4gIE1hc3Rlcl9LZXlzIFNIT1VMRCBiZQogICAgICAg ICAgICAgICAgICAgICByYW5kb20sIGJ1dCBtaWdodCBub3QgYmUgKGUuZy4sIGJhZGx5IGNob3Nl biBieSB0aGUKICAgICAgICAgICAgICAgICAgICAgdXNlcikuCgogICAgICAtIENvbnRleHQgOiAg ICBBIGJpbmFyeSBzdHJpbmcgY29udGFpbmluZyBpbmZvcm1hdGlvbiByZWxhdGVkIHRvCiAgICAg ICAgICAgICAgICAgICAgIHRoZSBzcGVjaWZpYyBjb25uZWN0aW9uIGZvciB0aGlzIGRlcml2ZWQg a2V5aW5nCiAgICAgICAgICAgICAgICAgICAgIG1hdGVyaWFsLCBhcyBkZWZpbmVkIGluCiAgICAg ICAgICAgICAgICAgICAgIFtJLUQuaWV0Zi10Y3BtLXRjcC1hdXRoLW9wdF0sIFNlY3Rpb24gNy4y XQoKCgoKCgpMZWJvdml0eiAmIFJlc2NvcmxhICAgICAgICBFeHBpcmVzIE1heSAxLCAyMDEwICAg ICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQ3J5 cHRvIGZvciBUQ1AtQU8gICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgoKICAgICAgLSBPdXRw dXRfTGVuZ3RoOiAgVGhlIGxlbmd0aCBpbiBiaXRzIG9mIHRoZSBrZXkgdGhhdCB0aGUgS0RGIHdp bGwKICAgICAgICAgICAgICAgICAgICAgcHJvZHVjZS4gIFRoaXMgbGVuZ3RoIG11c3QgYmUgdGhl IHNpemUgcmVxdWlyZWQgZm9yCiAgICAgICAgICAgICAgICAgICAgIHRoZSBNQUMgYWxnb3JpdGht IHRoYXQgd2lsbCB1c2UgdGhlIFBSRiByZXN1bHQgYXMgYQogICAgICAgICAgICAgICAgICAgICBz ZWVkLgoKICAgV2hlbiBpbnZva2VkLCBhIEtERiBnZW5lcmF0ZXMgYSBzdHJpbmcgb2YgbGVuZ3Ro IE91dHB1dF9MZW5ndGggYml0cwogICBiYXNlZCBvbiBNYXN0ZXJfS2V5IGFuZCBjb250ZXh0IHZh bHVlLiAgVGhpcyByZXN1bHQgbWF5IHRoZW4gYmUgdXNlZAogICBhcyBhIGNyeXB0b2dyYXBoaWMg a2V5IGZvciBhbnkgYWxnb3JpdGhtIHdoaWNoIHRha2VzIGFuIE91dHB1dF9MZW5ndGgKICAgbGVu Z3RoIGtleS4gIEEgS0RGIE1BWSBzcGVjaWZ5IGEgbWF4aW11bSBPdXRwdXRfTGVuZ3RoIHBhcmFt ZXRlci4KCjMuMS4xLiAgQ29uY3JldGUgS0RGcwoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3 byBLREYgYWxnb3JpdGhtcywgZWFjaCBwYWlyZWQgd2l0aCBhCiAgIGNvcnJlc3BvbmRpbmcgUFJG IGFsZ29yaXRobSBhcyBleHBsYWluZWQgYmVsb3c6CgoKICAgICAgICogIEtERl9ITUFDX1NIQTEg IGJhc2VkIG9uIFBSRi1ITUFDLVNIQTEgW1JGQzI0MDRdCiAgICAgICAqICBLREZfQUVTXzEyOF9D TUFDICBiYXNlZCBvbiBBRVMtQ01BQy1QUkYtMTI4IFtSRkM0NjE1XQoKCiAgIEVhY2gKCiAgIEJv dGggb2YgdGhlc2UgS0RGcyBhcmUgYmFzZWQgb24gdGhlIGl0ZXJhdGlvbiBtb2RlIEtERnMgc3Bl Y2lmaWVkIGluCiAgIFtOSVNULVNQODAwLTEwOF0uICBUaGlzIG1lYW5zIHRoYXQgdGhleSB1c2Ug YW4gdW5kZXJseWluZwogICBwc2V1ZG9yYW5kb20gZnVuY3Rpb24gKFBSRikgd2l0aCBhIGZpeGVk LWxlbmd0aCBvdXRwdXQgbGVuZ3RocywgMTI4CiAgIGJpdHMgaW4gdGhlIGNhc2Ugb2YgdGhlIEFF Uy1DTUFDLCBhbmQgMTYwIGJpdHMgaW4gdGhlIGNhc2Ugb2YgSE1BQy0KICAgU0hBMS4gIFRoZSBL REYgZ2VuZXJhdGVzIGFuIGFyYml0cmFyeSBudW1iZXIgb2Ygb3V0cHV0IGJpdHMgYnkKICAgb3Bl cmF0aW5nIHRoZSBQUkYgaW4gYSAiY291bnRlciBtb2RlIiwgd2hlcmUgZWFjaCBpbnZvY2F0aW9u IG9mIHRoZQogICBQUkYgdXNlcyBhIGRpZmZlcmVudCBpbnB1dCBibG9jayBkaWZmZXJlbnRpYXRl ZCBieSBhIGJsb2NrIGNvdW50ZXIuCgogICBFYWNoIGlucHV0IGJsb2NrIGlzIGNvbnN0cnVjdGVk IGFzIGZvbGxvd3M6CgogICAgICAgICggaSB8fCBMYWJlbCB8fCBDb250ZXh0IHx8IE91dHB1dF9M ZW5ndGgpCgogICAgICBXaGVyZQoKICAgICAgLSAifHwiOiAgICAgIEZvciBhbnkgWCB8fCBZLCAi fHwiIHJlcHJlc2VudHMgYSBjb25jYXRvbmF0aW9uCiAgICAgICAgICAgICAgICAgICBvcGVyYXRp b24gb2YgdGhlIGJpbmFyeSBzdHJpbmdzIFggYW5kIFkuCgogICAgICAtIGk6ICAgICAgICAgQSBj b3VudGVyLCBhIGJpbmFyeSBzdHJpbmcgdGhhdCBpcyBhbiBpbnB1dCB0byBlYWNoCiAgICAgICAg ICAgICAgICAgICBpdGVyYXRpb24gb2YgdGhlIFBSRiBpbiBjb3VudGVyIG1vZGUuICBUaGUgbnVt YmVyIG9mCiAgICAgICAgICAgICAgICAgICBpdGVyYXRpb25zIHdpbGwgZGVwZW5kIG9uIHRoZSBz cGVjaWZpYyBzaXplIG9mIHRoZQogICAgICAgICAgICAgICAgICAgT3V0cHV0X0xlbmd0aCBkZXNp cmVkIGZvciBhIGdpdmVuIE1BQy4KCgoKCgoKCkxlYm92aXR6ICYgUmVzY29ybGEgICAgICAgIEV4 cGlyZXMgTWF5IDEsIDIwMTAgICAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBDcnlwdG8gZm9yIFRDUC1BTyAgICAgICAgICAgICAgIE9jdG9iZXIg MjAwOQoKCgogICAgICAtIExhYmVsOiAgICAgQSBiaW5hcnkgc3RyaW5nIHRoYXQgY2xlYXJseSBp ZGVudGlmaWVzIHRoZSBwdXJwb3NlCiAgICAgICAgICAgICAgICAgICBvZiB0aGlzIEtERidzIGRl cml2ZWQga2V5aW5nIG1hdGVyaWFsLiAgRm9yIFRDUC1BTyB3ZQogICAgICAgICAgICAgICAgICAg dXNlIHRoZSBBU0NJSSBzdHJpbmcgIlRDUC1BTyIsIHdoZXJlIHRoZSBsYXN0CiAgICAgICAgICAg ICAgICAgICBjaGFyYWN0ZXIgaXMgdGhlIGNhcGl0YWwgbGV0dGVyICJPIiwgbm90IHRvIGJlCiAg ICAgICAgICAgICAgICAgICBjb25mdXNlZCB3aXRoIGEgemVyby4gIFdoaWxlIHRoaXMgbWF5IHNl ZW0gbGlrZQogICAgICAgICAgICAgICAgICAgb3ZlcmtpbGwgaW4gdGhpcyBzcGVjaWZpY2F0aW9u IHNpbmNlIFRDUC1BTyBvbmx5CiAgICAgICAgICAgICAgICAgICBkZXNjcmliZXMgb25lIGNhbGwg dG8gdGhlIEtERiwgaXQgaXMgaW5jbHVkZWQgaW4KICAgICAgICAgICAgICAgICAgIG9yZGVyIHRv IGNvbXBseSB3aXRoIEZJUFMgMTQwIGNlcnRpZmljYXRpb25zLgoKICAgICAgLSBDb250ZXh0IDog IFRoZSBjb250ZXh0IGFyZ3VtZW50IHByb3ZpZGVkIHRvIHRoZSBLREYgaW50ZXJmYWNlLAogICAg ICAgICAgICAgICAgICAgYXMgZGVzY3JpYmVkIGFib3ZlIGluIFNlY3Rpb24gMy4xIC4KCiAgICAg IC0gT3V0cHV0X0xlbmd0aDogIFRoZSBsZW5ndGggaW4gYml0cyBvZiB0aGUga2V5IHRoYXQgdGhl IEtERiB3aWxsCiAgICAgICAgICAgICAgICAgICBwcm9kdWNlLiAgVGhpcyBsZW5ndGggbXVzdCBi ZSB0aGUgc2l6ZSByZXF1aXJlZCBmb3IKICAgICAgICAgICAgICAgICAgIHRoZSBNQUMgYWxnb3Jp dGhtIHRoYXQgd2lsbCB1c2UgdGhlIFBSRiByZXN1bHQgYXMgYQogICAgICAgICAgICAgICAgICAg c2VlZC4KCiAgIFRoZSBvdXB1dCBvZiBtdXRpcGxlIFBSRiBpbnZvY2F0aW9ucyBpcyBzaW1wbHkg Y29uY2F0ZW5hdGVkLiAgRm9yIHRoZQogICBUcmFmZmljX0tleSwgdmFsdWVzIG9mIG11bHRpcGxl IFBSRiBpbnZvY2F0aW9ucyBhcmUgY29uY2F0ZW5hdGVkIGFuZAogICB0cnVuY2F0ZWQgYXMgbmVl ZGVkIHRvIGNyZWF0ZSBhIFRyYWZmaWNfS2V5IG9mIHRoZSBkZXNpcmVkIGxlbmd0aC4KICAgRm9y IGluc3RhbmNlLCBpZiBvbmUgd2VyZSB1c2luZyBLREZfSE1BQ19TSEExLCB3aGljaCB1c2VzIGEg MTYwLWJpdAogICBpbnRlcm5hbCBQUkYgdG8gZ2VuZXJhdGUgMzIwIGJpdHMgb2YgZGF0YSwgb25l IHdvdWxkIGV4ZWN1dGUgdGhlIFBSRgogICB0d2ljZSwgb25jZSB3aXRoIGk9MCBhbmQgb25jZSB3 aXRoIGk9MS4gIFRoZSByZXN1bHQgd291bGQgYmUgdGhlCiAgIGVudGlyZSBvdXRwdXQgb2YgdGhl IGZpcnN0IGludm9jYXRpb24gY29uY2F0ZW5hdGVkIHdpdGggdGhlIHNlY29uZAogICBpbnZvY2F0 aW9uLiAgRS5nLiwKCiAgICAgICAgICBUcmFmZmljX0tleSA9CiAgICAgICAgICAgIEtERl9hbGco TWFzdGVyX0tleSwgMCB8fCBMYWJlbCB8fCBDb250ZXh0IHx8IE91dHB1dF9sZW5ndGgpIHx8CiAg ICAgICAgICAgIEtERl9hbGcoTWFzdGVyX0tleSwgMSB8fCBMYWJlbCB8fCBDb250ZXh0IHx8IE91 dHB1dF9sZW5ndGgpCgogICBJZiB0aGUgbnVtYmVyIG9mIGJpdHMgcmVxdWlyZWQgaXMgbm90IGFu IGV2ZW4gbXVsdGlwbGUgb2YgdGhlIG91dHB1dAogICBzaXplIG9mIHRoZSBQUkYsIHRoZW4gdGhl IG91dHB1dCBvZiB0aGUgZmluYWwgaW52b2NhdGlvbiBvZiB0aGUgUFJGCiAgIGlzIHRydW5jYXRl ZCBhcyBuZWNlc3NhcnkuCgozLjEuMS4xLiAgS0RGX0hNQUNfU0hBMQoKICAgRm9yIEtERl9ITUFD X1NIQTE6CgogICAtIFBSRiBmb3IgS0RGX2FsZzogIEhNQUMtU0hBMSBbUkZDMjQwNF0uCgogICAt IFVzZTogICAgICAgSE1BQy1TSEExKEtleSwgSW5wdXQpLgoKICAgLSBLZXk6ICAgICAgIE1hc3Rl cl9LZXksIGNvbmZpZ3VyZWQgYnkgdXNlciwgYW5kIHBhc3NlZCB0byB0aGUgS0RGLgoKCgoKCgoK TGVib3ZpdHogJiBSZXNjb3JsYSAgICAgICAgRXhwaXJlcyBNYXkgMSwgMjAxMCAgICAgICAgICAg ICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENyeXB0byBmb3Ig VENQLUFPICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKCiAgIC0gSW5wdXQ6ICAgICAoIGkg fHwgTGFiZWwgfHwgQ29udGV4dCB8fCBPdXRwdXRfTGVuZ3RoKQoKICAgLSBPdXRwdXRfTGVuZ3Ro OiAgMTYwIGJpdHMuCgogICAtIFJlc3VsdDogICAgVHJhZmZpY19LZXksIHVzZWQgaW4gdGhlIE1B QyBmdW5jdGlvbiBieSBUQ1AtQU8uCgozLjEuMS4yLiAgS0RGX0FFU18xMjhfQ01BQwoKICAgRm9y IEtERl9BRVNfMTI4X0NNQUM6CgogICAtIFBSRiBmb3IgS0RGX2FsZzogIEFFUy1DTUFDLVBSRi0x MjggW1JGQzQ2MTVdLgoKICAgLSBVc2U6ICAgICAgIEFFUy1DTUFDKEtleSwgSW5wdXQpLgoKICAg LSBLZXk6ICAgICAgIE1hc3Rlcl9LZXkgKHNlZSB1c2FnZSBiZWxvdykKCiAgIC0gSW5wdXQ6ICAg ICAoIGkgfHwgTGFiZWwgfHwgQ29udGV4dCB8fCBPdXRwdXRfTGVuZ3RoKQoKICAgLSBPdXRwdXRf TGVuZ3RoOiAgMTI4IGJpdHMuCgogICAtIFJlc3VsdDogICAgVHJhZmZpY19LZXksIHVzZWQgaW4g dGhlIE1BQyBmdW5jdGlvbiBieSBUQ1AtQU8KCiAgIFRoZSBNYXN0ZXJfS2V5IGluIFRDUC1BTydz IGN1cnJlbnQgbWFudWFsIGtleWluZyBtZWNoYW5pc20gaXMgYQogICBzaGFyZWQgc2VjcmV0LCBl bnRlcmVkIGJ5IGFuIGFkbWluaXN0cmF0b3IuICBJdCBpcyBwYXNzZWQgdmlhIGFuIG91dC0KICAg b2YtYmFuZCBtZWNoYW5pc20gYmV0d2VlbiB0d28gZGV2aWNlcywgYW5kIG9mdGVuIGJldHdlZW4g dHdvCiAgIG9yZ2FuaXphdGlvbnMuICBUaGUgc2hhcmVkIHNlY3JldCBkb2VzIG5vdCBoYXZlIHRv IGJlIDE2IG9jdGV0cywgYW5kCiAgIHRoZSBsZW5ndGggbWF5IHZhcnkuICBIb3dldmVyLCBBRVNf MTI4X0NNQUMgcmVxdWlyZXMgYSBrZXkgb2YgZXhhY3RseQogICAxNiBvY3RldHMgKDEyOCBiaXRz KSBpbiBsZW5ndGguICBXZSBjb3VsZCBtYW5kYXRlIHRoYXQKICAgaW1wbGVtZW50YXRpb25zIGZv cmNlIGFkbWluaXN0cmF0b3JzIHRvIGlucHV0IE1hc3Rlcl9LZXlzIG9mIGV4YWN0bHkKICAgMTI4 IGJpdCBsZW5ndGggd2hlbiB1c2luZyBBRVNfMTI4X0NNQUMsIGFuZCB3aXRoIHN1ZmZpY2llbnQK ICAgcmFuZG9tbmVzcywgYnV0IHRoaXMgcGxhY2VzIHVuZHVlIGJ1cmRlbiBvbiB0aGUgaW1wbGVt ZW50b3JzIGFuZAogICBkZXBsb3llcnMuICBUaGlzIHNwZWNpZmljYXRpb24gUkVDT01NRU5EUyB0 aGF0IGRlcGxveWVycyB1c2UgYQogICByYW5kb21seSBnZW5lcmF0ZWQgMTI4LWJpdCBzdHJpbmcg YXMgdGhlIE1hc3Rlcl9LZXksIGJ1dCBhY2tub3dsZWRnZXMKICAgdGhhdCBkZXBsb3llcnMgbWF5 IG5vdC4KCiAgIFRvIGhhbmRsZSB2YXJpYWJsZSBsZW5ndGggTWFzdGVyX0tleXMgd2UgdXNlIHRo ZSBzYW1lIG1lY2hhbmlzbSBhcwogICBkZXNjcmliZWQgaW4gW1JGQzQ2MTVdLCBTZWN0IDMuICBG aXJzdCB3ZSB1c2UgQUVTXzEyOF9DTUFDIHdpdGggYQogICBmaXhlZCBrZXkgb2YgYWxsIHplcm9z IGFzIGEgInJhbmRvbW5lc3MgZXh0cmFjdG9yIiwgd2hpbGUgdXNpbmcgdGhlCiAgIHNoYXJlZCBz ZWNyZXQgTWFzdGVyX0tleSwgTUssIGFzIHRoZSBtZXNzYWdlIGlucHV0LCB0byBwcm9kdWNlIGEg MTI4CiAgIGJpdCBrZXkgRGVyaXZlZF9NYXN0ZXJfS2V5IChLKS4gIFNlY29uZCwgd2UgdXNlIHRo ZSByZXN1bHQgYXMgYSBrZXksCiAgIGFuZCBydW4gQUVTLTEyOF9DTUFDIGFnYWluLCB0aGlzIHRp bWUgdXNpbmcgdGhlIHJlc3VsdCBLIGFzIHRoZSBLZXksCiAgIGFuZCB0aGUgdHJ1ZSBpbnB1dCBi bG9jayBhcyB0aGUgSW5wdXQgdG8geWllbGQgdGhlIFRyYWZmaWNfS2V5IChUSykKICAgdXNlZCBp biB0aGUgTUFDIG92ZXIgdGhlIG1lc3NhZ2UuICBUaGUgZGVzY3JpcHRpb24gZm9sbG93czoKCgoK CgoKCkxlYm92aXR6ICYgUmVzY29ybGEgICAgICAgIEV4cGlyZXMgTWF5IDEsIDIwMTAgICAgICAg ICAgICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBDcnlwdG8g Zm9yIFRDUC1BTyAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCiAgICAgICAgICArKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysKICAgKyAgICAgICAgICAgICAgICAgICAgICAgIEtERi1BRVMtMTI4LUNNQUMgICAgICAg ICAgICAgICAgICAgICAgICAgICArCiAgICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogICArICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsKICAg KyBJbnB1dCAgOiBNSyAoTWFzdGVyX0tleSwgdGhlIHZhcmlhYmxlLWxlbmd0aCBzaGFyZWQgc2Vj cmV0KSAgICAgICArCiAgICsgICAgICAgIDogSSAoSW5wdXQsIGkuZS4sIHRoZSBpbnB1dCBkYXRh IG9mIHRoZSBQUkYpICAgICAgICAgICAgICAgKwogICArICAgICAgICA6IE1LbGVuIChsZW5ndGgg b2YgTUsgaW4gb2N0ZXRzKSAgICAgICAgICAgICAgICAgICAgICAgICAgICsKICAgKyAgICAgICAg OiBsZW4gKGxlbmd0aCBvZiBNIGluIG9jdGV0cykgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICArCiAgICsgT3V0cHV0IDogVEsgKFRyYWZmaWNfS2V5LCAxMjgtYml0IFBzZXVkby1SYW5kb20g VmFyaWFibGUpKwogICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICsKICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICsgVmFyaWFibGU6 IEsgKDEyOC1iaXQga2V5IGZvciBBRVMtQ01BQykgICAgICAgICAgICAgICAgICAgICAgICAgICAg KwogICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICsKICAgKyBTdGVwIDEuICAgSWYgTUtsZW4gaXMgZXF1YWwgdG8gMTYg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArCiAgICsgU3RlcCAxYS4gIHRoZW4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKwogICArICAg ICAgICAgICAgICAgSyA6PSBNSzsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICsKICAgKyBTdGVwIDFiLiAgZWxzZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArCiAgICsgICAgICAgICAgICAgICBLIDo9IEFFUy1DTUFD KDBeMTI4LCBNSywgTUtsZW4pOyAgICAgICAgICAgICAgICAgICAgKwogICArIFN0ZXAgMi4gICBU SyA6PSBBRVMtQ01BQyhLLCBJLCBsZW4pOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKwog ICArICAgICAgICAgICByZXR1cm4gVEs7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKwogICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICsKICAgKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCgoKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDEKCiAgIEluIHN0ZXAgMSwgdGhlIDEyOC1i aXQga2V5LCBLLCBmb3IgQUVTLUNNQUMgaXMgZGVyaXZlZCBhcyBmb2xsb3dzOgoKICAgbyBJZiB0 aGUgTWFzdGVyX0tleSwgTUssIHByb3ZpZGVkIGJ5IHRoZSBhZG1pbmlzdHJhdG9yIGlzIGV4YWN0 bHkgMTI4CiAgIGJpdHMsIHRoZW4gd2UgdXNlIGl0IGFzLWlzLgoKICAgbyBJZiBpdCBpcyBsb25n ZXIgb3Igc2hvcnRlciB0aGFuIDEyOCBiaXRzLCB0aGVuIHdlIGRlcml2ZSB0aGUga2V5IEsKICAg YnkgYXBwbHlpbmcgdGhlIEFFUy1DTUFDIGFsZ29yaXRobSB1c2luZyB0aGUgMTI4LWJpdCBhbGwt emVybyBzdHJpbmcKICAgYXMgdGhlIGtleSBhbmQgTUsgYXMgdGhlIGlucHV0IG1lc3NhZ2UuICBU aGlzIHN0ZXAgaXMgZGVzY3JpYmVkIGluCiAgIHN0ZXAgMWIuCgogICBJbiBzdGVwIDIsIHdlIGFw cGx5IHRoZSBBRVMtQ01BQyBhbGdvcml0aG0gYWdhaW4sIHRoaXMgdGltZSB1c2luZyBLCiAgIGFz IHRoZSBrZXkgYW5kIEkgYXMgdGhlIGlucHV0IG1lc3NhZ2UuCgogICBUaGUgb3V0cHV0IG9mIHRo aXMgYWxnb3JpdGhtIHJldHVybnMgVEssIHRoZSBUcmFmZmljX0tleSwgd2hpY2ggaXMKICAgMTI4 IGJpdHMgc3VpdGFibGUgZm9yIHVzZSBpbiB0aGUgTUFDIGZ1bmN0aW9uIG9uIGVhY2ggVENQIHNl Z21lbnQgb2YKICAgdGhlIGNvbm5lY3Rpb24uCgozLjEuMS4zLiAgVGlwcyBmb3IgVXNlciBJbnRl cmZhY2VzIHJlZ2FyZGluZyBLREZzCgogICBUaGlzIHNlY3Rpb24gcHJvdmlkZXMgc3VnZ2VzdGVk IHJlcHJlc2VudGF0aW9ucyBmb3IgdGhlIEtERnMgaW4KICAgaW1wbGVtZW50YXRpb24gdXNlciBp bnRlcmZhY2VzLiAgRm9sbG93aW5nIHRoZXNlIGd1aWRlbGluZXMgYWNyb3NzCiAgIGNvbW1vbiBp bXBsZW1lbnRhdGlvbnMgd2lsbCBtYWtlIGludGVyb3BlcmFiaWxpdHkgZWFzaWVyIGFuZCBzaW1w bGVyCgoKCkxlYm92aXR6ICYgUmVzY29ybGEgICAgICAgIEV4cGlyZXMgTWF5IDEsIDIwMTAgICAg ICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBDcnlw dG8gZm9yIFRDUC1BTyAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCiAgIGZvciBkZXBsb3ll cnMuCgogICBVSXMgU0hPVUxEIHJlZmVyIHRvIHRoZSBjaG9pY2Ugb2YgS0RGX0hNQUNfU0hBMSBh cyBzaW1wbHkgIlNIQTEiLgoKICAgVUlzIFNIT1VMRCByZWZlciB0byB0aGUgY2hvaWNlIG9mIEtE Rl9BRVNfMTI4X0NNQUMgYXMgc2ltcGx5CiAgICJBRVMxMjgiLgoKICAgVGhlIGluaXRpYWwgSUFO QSByZWdpc3RyeSB2YWx1ZXMgd2lsbCByZWZsZWN0IHRoZXNlIHR3byBlbnRyaWVzLgoKICAgVUlz IFNIT1VMRCB1c2UgS0RGX0hNQUNfU0hBMSBhcyB0aGUgZGVmYXVsdCBzZWxlY3Rpb24gaW4gVENQ LUFPCiAgIHNldHRpbmdzLiAgS0RGX0hNQUNfU0hBMSBpcyBwcmVmZXJyZWQgYXQgdGhpcyB0aW1l IGJlY2F1c2UgaXQgaGFzCiAgIHdpZGUgc3VwcG9ydCwgYmVpbmcgcHJlc2VudCBpbiBtb3N0IGlt cGxlbWVudGF0aW9ucyBpbiB0aGUKICAgbWFya2V0cGxhY2UuCgozLjIuICBNQUMgQWxnb3JpdGht cwoKICAgRWFjaCBNQUNfYWxnIGRlZmluZWQgZm9yIFRDUC1BTyBoYXMgdGhyZWUgZml4ZWQgZWxl bWVudHMgYXMgcGFydCBvZgogICBpdHMgZGVmaW5pdGlvbjoKCiAgIC0gS0RGX0FsZzogICAgIE5h bWUgb2YgdGhlIFRDUC1BTyBLREYgYWxnb3JpdGhtIHVzZWQgdG8gZ2VuZXJhdGUgdGhlCiAgICAg ICAgICAgICAgICAgIFRyYWZmaWNfS2V5CiAgIC0gS2V5X0xlbmd0aDogIExlbmd0aCBpbiBiaXRz IHJlcXVpcmVkIGZvciB0aGUgVHJhZmZpY19LZXkgdXNlZCBpbgogICAgICAgICAgICAgICAgICB0 aGlzIE1BQwogICAtIE91dHB1dDogICAgICBUaGUgZmluYWwgbGVuZ3RoIG9mIHRoZSBiaXRzIHVz ZWQgaW4gdGhlIFRDUC1BTyBNQUMKICAgICAgICAgICAgICAgICAgZmllbGQuICBUaGlzIHZhbHVl IG1heSBiZSBhIHRydW5jYXRpb24gb2YgdGhlIE1BQwogICAgICAgICAgICAgICAgICBmdW5jdGlv bidzIG9yaWdpbmFsIG91dHB1dCBsZW5ndGguCgogICBNQUNzIGNvbXB1dGVkIGZvciBUQ1AtQU8g aGF2ZSB0aGUgZm9sbG93aW5nIGludGVyZmFjZToKCiAgICAgICBNQUMgPSBNQUNfYWxnKFRyYWZm aWNfS2V5LCBNZXNzYWdlKQoKICAgd2hlcmU6CgoKICAgICAgLSBNQUNfYWxnOiAgICAgTUFDIEFs Z29yaXRobSB1c2VkCiAgICAgIC0gVHJhZmZpY19LZXk6IFZhcmlhYmxlOyB0aGUgcmVzdWx0IG9m IEtERi4KICAgICAgLSAgTWVzc2FnZSAgICAgVGhlIG1lc3NhZ2UgdG8gYmUgYXV0aGVudGljYXRl ZCwgYXMgc3BlY2lmaWVkIGluCiAgICAgICAgICAgICAgICAgICAgIFtJLUQuaWV0Zi10Y3BtLXRj cC1hdXRoLW9wdF0gU2VjdGlvbiA3LjEuCgogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0d28g TUFDIGFsZ29yaXRobSBvcHRpb25zIGZvciBnZW5lcmF0aW5nIHRoZQogICBNQUMgYXMgdXNlZCBi eSBUQ1AtQU86CgoKICAgICAgICogIEhNQUMtU0hBLTEtOTYgIGJhc2VkIG9uIFtSRkMyNDA0XQoK CgoKCgoKTGVib3ZpdHogJiBSZXNjb3JsYSAgICAgICAgRXhwaXJlcyBNYXkgMSwgMjAxMCAgICAg ICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENyeXB0 byBmb3IgVENQLUFPICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKCiAgICAgICAqICBBRVMt MTI4LUNNQUMtOTYgIGJhc2VkIG9uIFtSRkM0NDkzXQoKICAgQm90aCBwcm92aWRlIGEgaGlnaCBs ZXZlbCBvZiBzZWN1cml0eSBhbmQgZWZmaWNpZW5jeS4gIFRoZSBBRVMtMTI4LQogICBDTUFDLTk2 IGlzIHBvdGVudGlhbGx5IG1vcmUgZWZmaWNpZW50LCBwYXJ0aWN1bGFybHkgaW4gaGFyZHdhcmUs IGJ1dAogICBITUFDLVNIQS0xLTk2IGlzIG1vcmUgd2lkZWx5IHVzZWQgaW4gSW50ZXJuZXQgcHJv dG9jb2xzIGFuZCBpbiBtb3N0CiAgIGNhc2VzIGNvdWxkIGJlIHN1cHBvcnRlZCB3aXRoIGxpdHRs ZSBvciBubyBhZGRpdGlvbmFsIGNvZGUgaW4gdG9kYXkncwogICBkZXBsb3llZCBzb2Z0d2FyZSBh bmQgZGV2aWNlcy4KCiAgIEFuIGltcG9ydGFudCBhc3BlY3QgdG8gbm90ZSBhYm91dCB0aGVzZSBh bGdvcml0aG1zJyBkZWZpbml0aW9ucyBmb3IKICAgdXNlIGluIFRDUC1BTyBpcyB0aGUgZmFjdCB0 aGF0IHRoZSBNQUMgb3V0cHV0cyBhcmUgdHJ1bmNhdGVkIHRvIDk2CiAgIGJpdHMuICBBRVMtMTI4 LUNNQUMtOTYgcHJvZHVjZXMgYSAxMjggYml0IE1BQywgYW5kIEhNQUMgU0hBLTEKICAgcHJvZHVj ZXMgYSAxNjAgYml0IHJlc3VsdC4gIFRoZSBNQUMgb3V0cHV0IGFyZSB0aGVuIHRydW5jYXRlZCB0 byA5NgogICBiaXRzIHRvIHByb3ZpZGUgYSByZWFzb25hYmxlIHRyYWRlb2ZmIGJldHdlZW4gc2Vj dXJpdHkgYW5kIG1lc3NhZ2UKICAgc2l6ZSwgZm9yIGZpdHRpbmcgaW50byB0aGUgVENQLUFPIGhl YWRlci4KCjMuMi4xLiAgVGhlIFVzZSBvZiBITUFDLVNIQS0xLTk2CgogICBCeSBkZWZpbml0aW9u LCBITUFDIFtSRkMyMTA0XSByZXF1aXJlcyBhIGNyeXB0b2dyYXBoaWMgaGFzaCBmdW5jdGlvbi4K ICAgU0hBMSB3aWxsIGJlIHRoYXQgaGFzIGZ1bmN0aW9uIHVzZWQgZm9yIGF1dGhlbnRpY2F0aW5n IGFuZCBwcm92aWRpbmcKICAgaW50ZWdyaXR5IHZhbGlkYXRpb24gb24gVENQIHNlZ21lbnRzIHdp dGggSE1BQy4KCiAgIFRoZSB0aHJlZSBmaXhlZCBlbGVtZW50cyBmb3IgSE1BQy1TSEEtMS05NiBh cmU6CgogICAtIEtERl9BbGc6ICAgICBLREZfSE1BQ19TSEExLgogICAtIEtleV9MZW5ndGg6ICAx NjAgYml0cy4KICAgLSBPdXRwdXQ6ICAgICAgOTYgYml0cy4KCiAgIEZvcjoKCiAgICAgICAgTUFD ID0gTUFDX2FsZyAoVHJhZmZpY19LZXksIE1lc3NhZ2UpCgoKICAgSE1BQy1TSEEtMS05NiBmb3Ig VENQLUFPIGhhcyB0aGUgZm9sbG93aW5nIHZhbHVlczoKCgogICAgICAtIE1BQ19hbGc6ICAgICBI TUFDLVNIQTEKICAgICAgLSBUcmFmZmljX0tleTogVmFyaWFibGU7IHRoZSByZXN1bHQgb2YgdGhl IEtERi4KICAgICAgLSBNZXNzYWdlOiAgICAgVGhlIG1lc3NhZ2UgdG8gYmUgYXV0aGVudGljYXRl ZCwgYXMgc3BlY2lmaWVkIGluCiAgICAgICAgICAgICAgICAgICAgIFtJLUQuaWV0Zi10Y3BtLXRj cC1hdXRoLW9wdF0gU2VjdGlvbiA3LjEuCgoKCjMuMi4yLiAgVGhlIFVzZSBvZiBBRVMtMTI4LUNN QUMtOTYKCiAgIEluIHRoZSBjb250ZXh0IG9mIFRDUC1BTywgd2hlbiB3ZSBzYXkgIkFFUy0xMjgt Q01BQy05NiIgd2UgYWN0dWFsbHkKICAgZGVmaW5lIGEgdXNhZ2Ugb2YgQUVTLTEyOCBhcyBhIGNp cGhlci1iYXNlZCBNQUMgYWNjb3JkaW5nIHRvCiAgIFtOSVNULVNQODAwLTM4Ql0uCgoKCkxlYm92 aXR6ICYgUmVzY29ybGEgICAgICAgIEV4cGlyZXMgTWF5IDEsIDIwMTAgICAgICAgICAgICAgICAg IFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBDcnlwdG8gZm9yIFRDUC1B TyAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCiAgIFRoZSB0aHJlZSBmaXhlZCBlbGVtZW50 cyBmb3IgQUVTLTEyOC1DTUFDLTk2IGFyZToKCiAgIC0gS0RGX0FsZzogICAgIEtERl9BRVNfMTI4 X0NNQUMuCiAgIC0gS2V5X0xlbmd0aDogIDEyOCBiaXRzLgogICAtIE91dHB1dDogICAgICA5NiBi aXRzLgoKICAgRm9yOgoKICAgICAgICBNQUMgPSBNQUNfYWxnIChUcmFmZmljX0tleSwgTWVzc2Fn ZSkKCgogICBBRVMtMTI4LUNNQUMtOTYgZm9yIFRDUC1BTyBoYXMgdGhlIGZvbGxvd2luZyB2YWx1 ZXM6CgoKICAgICAgLSBNQUNfYWxnOiAgICAgQUVTLTEyOC1DTUFDLTk2IFtSRkM0NDkzXQogICAg ICAtIFRyYWZmaWNfS2V5OiBWYXJpYWJsZTsgdGhlIHJlc3VsdCBvZiB0aGUgS0RGLgogICAgICAt IE1lc3NhZ2U6ICAgICBUaGUgbWVzc2FnZSB0byBiZSBhdXRoZW50aWNhdGVkLCBhcyBzcGVjaWZp ZWQgaW4KICAgICAgICAgICAgICAgICAgICAgW0ktRC5pZXRmLXRjcG0tdGNwLWF1dGgtb3B0XSBT ZWN0aW9uIDcuMS4KCgoKCjQuICBDaGFuZ2UgSGlzdG9yeSAoUkZDIEVkaXRvcjogRGVsZXRlIGJl Zm9yZSBwdWJsaXNoaW5nKQoKICAgW05PVEUgVE8gUkZDIEVESVRPUjogdGhpcyBzZWN0aW9uIGZv ciB1c2UgZHVyaW5nIEktRCBzdGFnZSBvbmx5LgogICBQbGVhc2UgcmVtb3ZlIGJlZm9yZSBwdWJs aXNoaW5nIGFzIFJGQy5dCgogICBkcmFmdC1pZXRmLi4uLTAyIC0gNnRoIHN1Ym1pc3Npb24KCiAg IG8gIDMuMS4xLjEgJiAzLjEuMS4yLCBzL1BSRjovUFJGIGZvciBLREZfYWxnOiBmb3IgY2xhcmlm aWNhdGlvbgogICBvCgogICBkcmFmdC1pZXRmLi4uLTAxIC0gNXRoIHN1Ym1pc3Npb24KCiAgIG8g IHNpbXBsaWZpZWQgdGl0bGUgb2YgZG9jdW1lbnQgLSBUb3VjaAogICBvICBzdHJ1Y3R1cmUgb2Yg c2VjdCAzIGNoYW5nZWQ6IDMuMSBiZWNvbWVzICJDb25jcmV0ZSBLREYncyIgYW5kIHRoZQogICAg ICBkZXNjcmlwdGlvbiBvZiB0aGUgdHdvIEtERidzIGJlY2FtZSAzLjEuMS4xICYgMy4xLjEuMi4g dXNlZCBhCiAgICAgIHRlbXBsYXRlIChvZiBzb3J0cykgaW4gYm90aCBzZWN0aW9ucyB0aGF0IGNh biBiZSBlYXNpbHkgcmUtdXNlZCBieQogICAgICBhbnkgZnV0dXJlIEtERiBkZWZpbml0aW9uLgog ICBvICBpbiAzLjEsIHN3aXRjaGVkICJEZXJpdmVkX0tleSIgYmFjayB0byAiVHJhZmZpY19LZXki IGluIG9yZGVyIHRvCiAgICAgIHN5bmMgd2l0aCAtYXV0aC1vcHQgc3BlYy4KICAgbyAgaW4gMy4x LCBmb3IgVHJhZmZpY19LZXkgZGVmaW5pdGlvbiwgY2hhbmdlZCB0aGUgbmFtZSBvZiB0aGUKICAg ICAgZWxlbWVudCAiSW5wdXQiIHRvICJDb250ZXh0IiwgYW5kIHJlbW92ZWQgdGhlIGhhcmQgYmlu ZGluZyB0bwogICAgICBOSVNULVNQODAwLTEwOCBhdCB0aGUgZ2VuZXJpYyBpbnRlcmZhY2UgbGV2 ZWwuICBUaGUgTklTVCBpbmNsdXNpb24KICAgICAgaXMgc3RpbGwgcHJlc2VudCBpbiB0aGUgY29u Y3JldGUgZGVmaW5pdGlvbnMgb2YgdGhlIHR3byBwcmVzZW50ZWQKICAgICAgS0RGJ3MsIGJ1dCB0 aGlzIHdheSwgaWYgTklTVCBjaGFuZ2VzLCBvciBpZiB0aGUgY29tbXVuaXR5IHdhbnRzIHRvCiAg ICAgIGRlZmluZSBzb21lIG90aGVyLCBub24tTklTVC1saWtlIEtERnMsIHRoZSBpbnRlcmZhY2Ug aXMgZmxleGlibGUKICAgICAgZW5vdWdoIHRvIGhhbmRsZSB0aGF0LiAgQ2hhbmdlZCAiS0RGIiB0 byAiS0RGLWFsZyIuCgoKCkxlYm92aXR6ICYgUmVzY29ybGEgICAgICAgIEV4cGlyZXMgTWF5IDEs IDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDEyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBDcnlwdG8gZm9yIFRDUC1BTyAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCiAgIG8g IGluIDMuMiwgY2xhcmlmaWVkIHRoYXQgdGhlIG91dHB1dCBvZiB0aGUgZnVuY3Rpb24gaXMgY2Fs bGVkICJNQUMKICAgICAgPSIsIHRvIGhhdmUgYSBzaW1pbGFyIGxvb2sgYW5kIGZlZWwgdG8gc2Vj dCAzLjEncyBmdW5jdGlvbi4gYWxzbwogICAgICBjaGFuZ2VkIE1BQyhmb28pIHRvICJNQUNfYWxn IiwgYW5kIGRyb3BwZWQgIk91dHB1dF9MZW5ndGgiIGZyb20KICAgICAgdGhlIGZ1bmN0aW9uIHBh cmFtZXRlcnMsIGFzIGl0IGlzIHNwZWNpZmllZCBhcyBhIGZpeGVkIGVsZW1lbnQgZm9yCiAgICAg IGVhY2ggTUFDIGRlZmluZWQsIGJ1dCBub3QgcGFzc2VkIGFzIGEgcGFyYW1ldGVyIG9mIHRoZSBm dW5jdGlvbi4KICAgbyAgc2VjdCAzLjIgLSByZW1vdmVkICJ0cnVuY2F0aW9uIiBmcm9tIGludGVy ZmFjZSBkZWZpbml0aW9uLCBhbmQKICAgICAgcGxhY2VkIGl0IGFzIGEgZml4ZWQgZWxlbWVudCBv ZiB0aGUgTUFDIGRlZmluaXRpb24uIHNlY3QgMy4yLjEgYW5kCiAgICAgIDMuMi4yIC0gY2hhbmdl ZCAidHJ1bmNhdGlvbjoiIGZpZWxkIHRvICJPdXRwdXQ6Ii4gIFJlbW92ZWQgdGV4dAogICAgICBh Ym91dCBSRkM0NDkzIGZyb20gZW5kIG9mIDMuMi4yLgogICBvICBzZWN0IDMuMS4xLjIsIGNoYW5n ZWQgYmFjayB0byBmb2xsb3cgNDYxNSBleGFjdGx5IChhZ3JlZW1lbnQgd2l0aAogICAgICBwb2xr LCBtY2dyZXcsIGxlYm92aXR6LCBla3IpCiAgIG8gIHNlY3QgMy4xLjEuMywgZGVsZXRlZCB0aGUg Zm9sbG93aW5nOiAiV2hlbiBzdWNoIGEgdGltZSBhcnJpdmVzIGFzCiAgICAgIEtERl9BRVNfMTI4 X0NNQUMgYmVjb21lcyB3aWRlbHkgZGVwbG95ZWQsIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlCiAg ICAgIHVwZGF0ZWQgc28gdGhhdCBpdCBiZWNvbWVzIHRoZSBkZWZhdWx0IEtERiBvbiBpbXBsZW1l bnRhdGlvbnMuIgogICBvICBhZGRlZCB0aGUgdHdvIElBTkEgdmFsdWVzIFNIQTEgYW5kIEFFUzEy OCB0byBJQU5BIHNlY3Rpb24KICAgbyAgTWlub3IgdGV4dCBjaGFuZ2UgaW4gc2VjdGlvbiAzLjEg YW5kIDMuMiwgdG8gdGhlIGRlZmluaXRpb24gb2YKICAgICAgIkNvbnRleHQiIGluIGJvdGggLSBK b2UgVG91Y2gKICAgbyAgbWlub3IgdGV4dCBjaGFuZ2UgaW4gMy4xLjEgY2xhcmlmeWluZyB0aGF0 IHRoZSBjb25jYXRlbmF0aW9uIGlzIG9mCiAgICAgIGJpbmFyeSBzdHJpbmdzIC0gSm9lIFRvdWNo CiAgIG8gIGNvcHkgZWRpdHMgZm9yIHJlYWQtYWJpbGl0eSB0aHJvdWdob3V0IC0gVG91Y2gKCiAg IGRyYWZ0LWlldGYuLi4tMDAgLSA0dGggc3VibWlzc2lvbgoKICAgbyAgU3VibWl0dGluZyBkcmFm dC1sZWJvdml0ei4uLi0wMiBhcyBhIFdHIGRvY3VtZW50LiAgQWRkZWQgRUtSIGFzCiAgICAgIGNv LSBhdXRob3IsIGFuZCBnYXZlIGhpbSBjcmVkaXQgZm9yIHJld3JpdGUgb2Ygc2VjdCAzLjEueCAu CgogICBkcmFmdC1sZWJvdml0ei4uLi0wMiAtIDNyZCBzdWJtaXNzaW9uCgogICBvICBjbGVhbmVk IHVwIGV4cGxhbmF0aW9uIGluIDMuMS4yCiAgIG8gIGluIDMuMS4yLCBjaGFuZ2VkIHRoZSBrZXkg ZXh0cmFjdG9yIG1lY2hhbmlzbSBiYWNrLCBmcm9tIHVzaW5nIGFuCiAgICAgIGFscGhhbnVtZXJp YyBzdHJpbmcgZm9yIHRoZSBmaXhlZCBrZXkgQyB0byB1c2UgMF4xMjggYXMgdGhlIGtleQogICAg ICAoYXMgaXQgd2FzIGluIC0wMCkgKFBvbGsgJiBFa3IpCiAgIG8gIGRlbGV0ZWQgY3V0LWFuZC1w YXN0ZSBlcnJvciB0ZXh0IGZyb20gc2VjdCAzLjEgYmV0d2VlbiAibGFiZWwiIGFuZAogICAgICAi Y29udGV4dCIKICAgbyAgY2hhbmdlZCAiY29ubl9rZXkiIHRvICJ0cmFmZmljX2tleSIgdGhyb3Vn aG91dCwgdG8gZm9sbG93IGF1dGgtCiAgICAgIG9wdC0wNQogICBvICBjaGFuZ2VkICJ0c2FkIiB0 byAibWt0IiB0aHJvdWdob3V0LCB0byBmb2xsb3cgYXV0aC1vcHQtMDUKICAgbyAgY2hhbmdlZCAi Y29ubl9ibG9jayIgdG8gImRhdGFfYmxvY2siIHRocm91Z2hvdXQsIHRvIGZvbGxvdyBhdXRoLQog ICAgICBvcHQtMDUKCiAgIGRyYWZ0LWxlYm92aXR6Li4uLTAxLSAybmQgc3VibWlzc2lvbgoKICAg byAgcmVtb3ZlZCB0aGUgd2hvbGUgc2VjdGlvbiBvbiBsYWJlbHMgKHByZXZpb3VzbHkgc2VjdGlv biA0KSwgcGVyIFdHCiAgICAgIGNvbnNlbnN1cyBhdCBJRVRGNzQuICBBZGRlZCAzLjEuMyB0byBz cGVjaWZ5IHRoYXQgaW1wbGVtZW50YXRpb25zCiAgICAgIFNIT1VMRCBtYWtlIEhNQUMtU0hBMSB0 aGUgZGVmYXVsdCBjaG9pY2UgZm9yIHRoZSB0aW1lIGJlaW5nLCBhbmQKICAgICAgdG8gc3VnZ2Vz dCBjb21tb24gbmFtZXMgZm9yIHRoZSBLREYncyB1bml2ZXJzYWxseSBpbiBVSSdzLgoKCgoKCkxl Ym92aXR6ICYgUmVzY29ybGEgICAgICAgIEV4cGlyZXMgTWF5IDEsIDIwMTAgICAgICAgICAgICAg ICAgIFtQYWdlIDEzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBDcnlwdG8gZm9yIFRD UC1BTyAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCiAgIG8gIGNoYW5nZWQgS0RGID0gUFJG Li4uIHRvIERlcml2ZWRfS2V5ID0gS0RGLi4uICAoRUtSKQogICBvICBhZGRlZCB0aGUgdGV4dCBv biBob3cgdG8gZGVhbCB3aXRoIGZ1dHVyZSBLREYgdG8gZW5kIG9mIHMzLjEgKEVLUikKICAgbyAg cmVtb3ZlZCByZWZlcmVuY2VzIHRvIFRDUC1BTyAibWFudWFsIGtleSBtb2RlIi4gIENoYW5nZWQg dG8gVENQLQogICAgICBBTydzICJjdXJyZW50IG1vZGUgb2YgbWFudWFsIGtleWluZyIuICAoVG91 Y2gpCiAgIG8gIHJlbW92ZWQgdGhlIHdob2xlIE1VU1QtIC8gU0hPVUxEKyB0aGluZy4gIEJvdGgg S0RGJ3MgYXJlIE1VU1Qgbm93LAogICAgICBwZXIgd2cgY29uc2Vuc3VzIGF0IGlldGY3NC4KICAg byAgaW4gMy4xLjIsIGNoYW5nZWQgdGhlIG1lY2hhbmlzbSB0byBmb3JjZSB0aGUgSyB0byBiZSAx MjhiaXRzIGZyb20KICAgICAgdXNpbmcgMF4xMjgsIHRvIHVzaW5nIGEgZml4ZWQgMTI4LWJpdCBz dHJpbmcgb2YgcmFuZG9tIGNoYXJhY3RlcnMKICAgICAgKERhdmUgTWNHcmV3KQogICBvICBzZWN0 IDMuMSwgaW4gSW5wdXQgZGVzY3JpcHRpb24sIGRyb3BwZWQgIjB4MDAiLiAgQWRkZWQgIk5PVEUi CiAgICAgIGV4cGxhaW5pbmcgd2h5IHJpZ2h0IGFmdGVyIHRoZSBvdXRwdXRfbGVuZ3RoIGRlc2Ny aXB0aW9uLgogICBvICBjbGVhbmVkIHVwIGFsbCByZWZlcmVuY2VzCiAgIG8gIGNvcHkgZWRpdGlu ZwoKICAgZHJhZnQtbGVib3ZpdHouLi4tMDAgLSBvcmlnaW5hbCBzdWJtaXNzaW9uCgoKNS4gIE5l ZWRzIFdvcmsgaW4gTmV4dCBEcmFmdCAoUkZDIEVkaXRvcjogRGVsZXRlIEJlZm9yZSBQdWJsaXNo aW5nKQoKICAgW05PVEUgVE8gUkZDIEVESVRPUjogdGhpcyBzZWN0aW9uIGZvciB1c2UgZHVyaW5n IEktRCBzdGFnZSBvbmx5LgogICBQbGVhc2UgcmVtb3ZlIGJlZm9yZSBwdWJsaXNoaW5nIGFzIFJG Qy5dCgogICBMaXN0IG9mIHN0dWZmIHRoYXQgc3RpbGwgbmVlZHMgd29yawogICBvICBzaG91bGQg YmUgcmVhZHkgZm9yIFdHIExDLiAgQW55IGNoYW5nZXMgd2lsbCBjb21lIGZyb20gZmluYWwgV0cK ICAgICAgcmV2aWV3IG9yIElFU0cgcmV2aWV3LgoKCjYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9u cwoKICAgVGhpcyBkb2N1bWVudCBpbmhlcml0cyBhbGwgb2YgdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIG9mIHRoZQogICBUQ1AtQU8sIHRoZSBBRVMtQ01BQywgYW5kIHRoZSBITUFDLVNIQS0x IGRvY3VtZW50cy4KCiAgIFRoZSBzZWN1cml0eSBvZiBjcnlwdG9ncmFwaGljLWJhc2VkIHN5c3Rl bXMgZGVwZW5kcyBvbiBib3RoIHRoZQogICBzdHJlbmd0aCBvZiB0aGUgY3J5cHRvZ3JhcGhpYyBh bGdvcml0aG1zIGNob3NlbiBhbmQgdGhlIHN0cmVuZ3RoIG9mCiAgIHRoZSBrZXlzIHVzZWQgd2l0 aCB0aG9zZSBhbGdvcml0aG1zLiAgVGhlIHNlY3VyaXR5IGFsc28gZGVwZW5kcyBvbgogICB0aGUg ZW5naW5lZXJpbmcgb2YgdGhlIHByb3RvY29sIHVzZWQgYnkgdGhlIHN5c3RlbSB0byBlbnN1cmUg dGhhdAogICB0aGVyZSBhcmUgbm8gbm9uLWNyeXB0b2dyYXBoaWMgd2F5cyB0byBieXBhc3MgdGhl IHNlY3VyaXR5IG9mIHRoZQogICBvdmVyYWxsIHN5c3RlbS4KCiAgIENhcmUgc2hvdWxkIGFsc28g YmUgdGFrZW4gdG8gZW5zdXJlIHRoYXQgdGhlIHNlbGVjdGVkIGtleSBpcwogICB1bnByZWRpY3Rh YmxlLCBhdm9pZGluZyBhbnkga2V5cyBrbm93biB0byBiZSB3ZWFrIGZvciB0aGUgYWxnb3JpdGht CiAgIGluIHVzZS4gXVtSRkM0MDg2XSBjb250YWlucyBoZWxwZnVsIGluZm9ybWF0aW9uIG9uIGJv dGgga2V5CiAgIGdlbmVyYXRpb24gdGVjaG5pcXVlcyBhbmQgY3J5cHRvZ3JhcGhpYyByYW5kb21u ZXNzLgoKICAgTm90ZSB0aGF0IGluIHRoZSBjb21wb3NpdGlvbiBvZiBLREZfQUVTXzEyOF9DTUFD LCB0aGUgUFJGIG5lZWRzIGEgMTI4CiAgIGJpdCAvIDE2IGJ5dGUga2V5IGFzIHRoZSBzZWVkLiAg SG93ZXZlciwgZm9yIGNvbnZlbmllbmNlIHRvIHRoZQogICBhZG1pbmlzdHJhdG9ycy9kZXBsb3ll cnMsIHdlIGRpZCBub3Qgd2FudCB0byBmb3JjZSB0aGVtIHRvIGVudGVyIGEgMTYKICAgYnl0ZSBN YXN0ZXJfS2V5LiBTbyB3ZSBzcGVjaWZpZWQgdGhlIHN1Yi1rZXkgcm91dGluZSB0aGF0IGNvdWxk CgoKCkxlYm92aXR6ICYgUmVzY29ybGEgICAgICAgIEV4cGlyZXMgTWF5IDEsIDIwMTAgICAgICAg ICAgICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBDcnlwdG8g Zm9yIFRDUC1BTyAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwOQoKCiAgIGhhbmRsZSBhIHZhcmlh YmxlIGxlbmd0aCBNYXN0ZXJfS2V5LCBvbmUgdGhhdCBtaWdodCBiZSBsZXNzIHRoYW4gMTYKICAg Ynl0ZXMuICBUaGlzIGRvZXMgTk9UIG1lYW4gdGhhdCBhZG1pbmlzdHJhdG9ycyBhcmUgc2FmZSB0 byB1c2Ugd2VhawogICBrZXlzLiAgQWRtaW5pc3RyYXRvcnMgYXJlIGVuY291cmFnZWQgdG8gZm9s bG93IFtSRkM0MDg2XSBhcyBsaXN0ZWQKICAgYWJvdmUuICBXZSBzaW1wbHkgYXR0ZW1wdGVkIHRv ICJwdXQgYSBmZW5jZSBhcm91bmQgc3R1cGlkaXR5IiwgaW4gYXMKICAgbXVjaCBhcyBwb3NzaWJs ZS4KCiAgIFRoaXMgZG9jdW1lbnQgY29uY2VybnMgaXRzZWxmIHdpdGggdGhlIHNlbGVjdGlvbiBv ZiBjcnlwdG9ncmFwaGljCiAgIGFsZ29yaXRobXMgZm9yIHRoZSB1c2Ugb2YgVENQLUFPLiAgVGhl IGFsZ29yaXRobXMgaWRlbnRpZmllZCBpbiB0aGlzCiAgIGRvY3VtZW50IGFzICJNVVNUIGltcGxl bWVudCIgb3IgIlNIT1VMRCBpbXBsZW1lbnQiIGFyZSBub3Qga25vd24gdG8KICAgYmUgYnJva2Vu IGF0IHRoZSBjdXJyZW50IHRpbWUsIGFuZCBjcnlwdG9ncmFwaGljIHJlc2VhcmNoIHNvIGZhcgog ICBsZWFkcyB1cyB0byBiZWxpZXZlIHRoYXQgdGhleSB3aWxsIGxpa2VseSByZW1haW4gc2VjdXJl IGludG8gdGhlCiAgIGZvcmVzZWVhYmxlIGZ1dHVyZS4gIFNvbWUgb2YgdGhlIGFsZ29yaXRobXMg bWF5IGJlIGZvdW5kIGluIHRoZQogICBmdXR1cmUgdG8gaGF2ZSBwcm9wZXJ0aWVzIHNpZ25pZmlj YW50bHkgd2Vha2VyIHRoYW4gdGhvc2UgdGhhdCB3ZXJlCiAgIGJlbGlldmVkIGF0IHRoZSB0aW1l IHRoaXMgZG9jdW1lbnQgd2FzIHByb2R1Y2VkLiAgRXhwZWN0IHRoYXQgbmV3CiAgIHJldmlzaW9u cyBvZiB0aGlzIGRvY3VtZW50IHdpbGwgYmUgaXNzdWVkIGZyb20gdGltZSB0byB0aW1lLiAgQmUg c3VyZQogICB0byBzZWFyY2ggZm9yIG1vcmUgcmVjZW50IHZlcnNpb25zIG9mIHRoaXMgZG9jdW1l bnQgYmVmb3JlCiAgIGltcGxlbWVudGluZy4KCgo3LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAg SUFOQSBoYXMgY3JlYXRlZCBhbmQgd2lsbCBtYWludGFpbiBhIHJlZ2lzdHJ5IGNhbGxlZCwgIkNy eXB0b2dyYXBoaWMKICAgQWxnb3JpdGhtcyBmb3IgVENQLUFPIi4gIFRoZSByZWdpc3RyeSBjb25z aXN0cyBvZiBhIHRleHQgc3RyaW5nIGFuZAogICBhbiBSRkMgbnVtYmVyIHRoYXQgbGlzdHMgdGhl IGFzc29jaWF0ZWQgdHJhbnNmb3JtKHMpLiAgTmV3IGVudHJpZXMKICAgY2FuIGJlIGFkZGVkIHRv IHRoZSByZWdpc3RyeSBvbmx5IGFmdGVyIFJGQyBwdWJsaWNhdGlvbiBhbmQgYXBwcm92YWwKICAg YnkgYW4gZXhwZXJ0IGRlc2lnbmF0ZWQgYnkgdGhlIElFU0cuCgogICBUaGUgcmVnaXN0cnkgaGFz IHRoZSBmb2xsb3dpbmcgaW5pdGlhbCB2YWx1ZXM6CgoKICAgICAgU0hBMSAgICAgICAgICAgW1Ro aXMgUkZDIHdoZW4gcHVibGlzaGVkXQogICAgICBBRVMxMjggICAgICAgICBbVGhpcyBSRkMgd2hl biBwdWJsaXNoZWRdCgoKCjguICBBY2tub3dsZWRnZW1lbnRzCgogICBFcmljICJFS1IiIFJlc2Nv cmxhLCB3aG8gcHJvdmlkZWQgYSB0b24gb2YgaW5wdXQgYW5kIGZlZWRiYWNrLAogICBpbmNsdWRp bmcgYSBzb21ld2hhdCBoZWF2eSByZS13cml0ZSBvZiBzZWN0aW9uIDMuMS54LCBlYXJuaW5nIGhp bSBhbmQKICAgYXV0aG9yIHNsb3Qgb24gdGhlIGRvY3VtZW50LgoKICAgUGF1bCBIb2ZmbWFuLCBm cm9tIHdob3NlIFtSRkM0MzA4XSBJIHNvbWV0aW1lcyBjb3BpZWQsIHRvIHF1aWNrbHkKICAgY3Jl YXRlIGEgZmlyc3QgZHJhZnQgaGVyZS4KCiAgIFRpbSBQb2xrLCB3aG9zZSBlbWFpbCBzdW1tYXJp emluZyBTQUFHJ3MgZ3VpZGFuY2UgdG8gVENQTSBvbiB0aGUgdHdvCiAgIGhhc2ggYWxnb3JpdGht cyBmb3IgVENQLUFPIGlzIGxhcmdlbHkgY3V0IGFuZCBwYXN0ZWQgaW50byB2YXJpb3VzCiAgIHNl Y3Rpb25zIG9mIHRoaXMgZG9jdW1lbnQuCgoKCgpMZWJvdml0eiAmIFJlc2NvcmxhICAgICAgICBF eHBpcmVzIE1heSAxLCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgQ3J5cHRvIGZvciBUQ1AtQU8gICAgICAgICAgICAgICBPY3RvYmVy IDIwMDkKCgogICBKZWZmIFNjaGlsbGVyLCBEb25hbGQgRWFzdGxha2UgYW5kIHRoZSBJUHNlYyBX Rywgd2hvc2UgW1JGQzQzMDddICYKICAgW1JGQzQzMDVdIHRleHQgd2FzIGNvbnN1bHRlZCBhbmQg c29tZXRpbWVzIHVzZWQgaW4gdGhlIFJlcXVpcmVtZW50cwogICBTZWN0aW9uIDIgc2VjdGlvbiBv ZiB0aGlzIGRvY3VtZW50LgoKICAgKEluIG90aGVyIHdvcmRzLCBJIHdhcyB0cnVseSBvbmx5IGFu IGVkaXRvciBvZiBvdGhlcnMnIHRleHQgaW4KICAgY3JlYXRpbmcgdGhpcyBkb2N1bWVudC4pCgog ICBFcmljICJFS1IiIFJlc2NvcmxhIGFuZCBCcmlhbiBXZWlzLCB3aG8gYnJvdWdodCB0byBjbGFy aXR5IHRoZSBpc3N1ZXMKICAgd2l0aCB0aGUgaW5wdXRzIHRvIFBSRnMgZm9yIHRoZSBLREZzLiAg RUtSIHdhcyBhbHNvIG9mIGdyZWF0CiAgIGFzc2lzdGFuY2UgaW4gaG93IHRvIHN0cnVjdHVyZSB0 aGUgdGV4dCwgYXMgd2VsbCBhcyBoZWxwaW5nIHRvIGd1aWRlCiAgIGdvb2QgY3J5cHRvZ3JhcGhp YyBkZWNpc2lvbnMuCgogICBUaGUgVENQTSB3b3JraW5nIGdyb3VwLCB3aG8gcHV0IHVwIHdpdGgg YWxsIHVzIGNyeXB0byBhbmQgcm91dGluZwogICBmb2xrcyBEb1MnaW5nIHRoZWlyIFdHIGZvciAy IHllYXJzLCBhbmQgd2hvIHByb3ZpZGVkIHJldmlld3Mgb2YgdGhpcwogICBkb2N1bWVudC4KCgo5 LiAgUmVmZXJlbmNlcwoKOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJLUQuaWV0Zi10 Y3BtLXRjcC1hdXRoLW9wdF0KICAgICAgICAgICAgICBUb3VjaCwgSi4sIE1hbmtpbiwgQS4sIGFu ZCBSLiBCb25pY2EsICJUaGUgVENQCiAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24gT3B0aW9u IiwgZHJhZnQtaWV0Zi10Y3BtLXRjcC1hdXRoLW9wdC0wNwogICAgICAgICAgICAgICh3b3JrIGlu IHByb2dyZXNzKSwgT2N0b2JlciAyMDA5LgoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktl eSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJl bWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoKOS4yLiAgSW5mb3Jt YXRpdmUgUmVmZXJlbmNlcwoKICAgW0hNQUMtQVRUQUNLXQogICAgICAgICAgICAgICJPbiB0aGUg U2VjdXJpdHkgb2YgSE1BQyBhbmQgTk1BQyBCYXNlZCBvbiBIQVZBTCwgTUQ0LAogICAgICAgICAg ICAgIE1ENSwgU0hBLTAgYW5kIFNIQS0xIiIsIDIwMDYsCiAgICAgICAgICAgICAgPGh0dHA6Ly9l cHJpbnQuaWFjci5vcmcvMjAwNi8xODcKICAgICAgICAgICAgICBodHRwOi8vd3d3LnNwcmluZ2Vy bGluay5jb20vY29udGVudC8wMHc0djYyNjUxMDAxMzAzPi4KCiAgIFtJLUQubmFydGVuLWlhbmEt Y29uc2lkZXJhdGlvbnMtcmZjMjQzNGJpc10KICAgICAgICAgICAgICBOYXJ0ZW4sIFQuIGFuZCBI LiBBbHZlc3RyYW5kLCAiR3VpZGVsaW5lcyBmb3IgV3JpdGluZyBhbgogICAgICAgICAgICAgIElB TkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzIiwKICAgICAgICAgICAgICBkcmFmdC1u YXJ0ZW4taWFuYS1jb25zaWRlcmF0aW9ucy1yZmMyNDM0YmlzLTA5ICh3b3JrIGluCiAgICAgICAg ICAgICAgcHJvZ3Jlc3MpLCBNYXJjaCAyMDA4LgoKICAgW05JU1QtU1A4MDAtMTA4XQogICAgICAg ICAgICAgIE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3ksCiAg ICAgICAgICAgICAgIlJlY29tbWVuZGF0aW9uIGZvciBLZXkgRGVyaXZhdGlvbiBVc2luZyBQc2V1 ZG9yYW5kb20KICAgICAgICAgICAgICBGdW5jdGlvbnMiLCBTUCA4MDAtMTA4LCBBcHJpbCAyMDA4 LgoKCgoKTGVib3ZpdHogJiBSZXNjb3JsYSAgICAgICAgRXhwaXJlcyBNYXkgMSwgMjAxMCAgICAg ICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIENyeXB0 byBmb3IgVENQLUFPICAgICAgICAgICAgICAgT2N0b2JlciAyMDA5CgoKICAgW05JU1QtU1A4MDAt MzhCXQogICAgICAgICAgICAgIE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRl Y2hub2xvZ3ksCiAgICAgICAgICAgICAgIlJlY29tbWVuZGF0aW9uIGZvciBCbG9jayBDaXBoZXIg TW9kZXMgb2YgT3BlcmF0aW9uOiBUaGUKICAgICAgICAgICAgICBDTUFDIE1vZGUgZm9yIEF1dGhl bnRpY2F0aW9uIiwgU1AgODAwLTM4QiwgTWF5IDIwMDUuCgogICBbUkZDMjEwNF0gIEtyYXdjenlr LCBILiwgQmVsbGFyZSwgTS4sIGFuZCBSLiBDYW5ldHRpLCAiSE1BQzogS2V5ZWQtCiAgICAgICAg ICAgICAgSGFzaGluZyBmb3IgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiIsIFJGQyAyMTA0LAogICAg ICAgICAgICAgIEZlYnJ1YXJ5IDE5OTcuCgogICBbUkZDMjQwMV0gIEtlbnQsIFMuIGFuZCBSLiBB dGtpbnNvbiwgIlNlY3VyaXR5IEFyY2hpdGVjdHVyZSBmb3IgdGhlCiAgICAgICAgICAgICAgSW50 ZXJuZXQgUHJvdG9jb2wiLCBSRkMgMjQwMSwgTm92ZW1iZXIgMTk5OC4KCiAgIFtSRkMyNDA0XSAg TWFkc29uLCBDLiBhbmQgUi4gR2xlbm4sICJUaGUgVXNlIG9mIEhNQUMtU0hBLTEtOTYgd2l0aGlu CiAgICAgICAgICAgICAgRVNQIGFuZCBBSCIsIFJGQyAyNDA0LCBOb3ZlbWJlciAxOTk4LgoKICAg W1JGQzI0MDZdICBLZW50LCBTLiBhbmQgUi4gQXRraW5zb24sICJJUCBFbmNhcHN1bGF0aW5nIFNl Y3VyaXR5CiAgICAgICAgICAgICAgUGF5bG9hZCAoRVNQKSIsIFJGQyAyNDA2LCBOb3ZlbWJlciAx OTk4LgoKICAgW1JGQzQwODZdICBFYXN0bGFrZSwgRC4sIFNjaGlsbGVyLCBKLiwgYW5kIFMuIENy b2NrZXIsICJSYW5kb21uZXNzCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBTZWN1cml0 eSIsIEJDUCAxMDYsIFJGQyA0MDg2LCBKdW5lIDIwMDUuCgogICBbUkZDNDMwNV0gIEVhc3RsYWtl LCBELiwgIkNyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIEltcGxlbWVudGF0aW9uCiAgICAgICAgICAg ICAgUmVxdWlyZW1lbnRzIGZvciBFbmNhcHN1bGF0aW5nIFNlY3VyaXR5IFBheWxvYWQgKEVTUCkg YW5kCiAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24gSGVhZGVyIChBSCkiLCBSRkMgNDMwNSwg RGVjZW1iZXIgMjAwNS4KCiAgIFtSRkM0MzA3XSAgU2NoaWxsZXIsIEouLCAiQ3J5cHRvZ3JhcGhp YyBBbGdvcml0aG1zIGZvciBVc2UgaW4gdGhlCiAgICAgICAgICAgICAgSW50ZXJuZXQgS2V5IEV4 Y2hhbmdlIFZlcnNpb24gMiAoSUtFdjIpIiwgUkZDIDQzMDcsCiAgICAgICAgICAgICAgRGVjZW1i ZXIgMjAwNS4KCiAgIFtSRkM0MzA4XSAgSG9mZm1hbiwgUC4sICJDcnlwdG9ncmFwaGljIFN1aXRl cyBmb3IgSVBzZWMiLCBSRkMgNDMwOCwKICAgICAgICAgICAgICBEZWNlbWJlciAyMDA1LgoKICAg W1JGQzQ0OTNdICBTb25nLCBKSC4sIFBvb3ZlbmRyYW4sIFIuLCBMZWUsIEouLCBhbmQgVC4gSXdh dGEsICJUaGUKICAgICAgICAgICAgICBBRVMtQ01BQyBBbGdvcml0aG0iLCBSRkMgNDQ5MywgSnVu ZSAyMDA2LgoKICAgW1JGQzQ2MTVdICBTb25nLCBKLiwgUG9vdmVuZHJhbiwgUi4sIExlZSwgSi4s IGFuZCBULiBJd2F0YSwgIlRoZQogICAgICAgICAgICAgIEFkdmFuY2VkIEVuY3J5cHRpb24gU3Rh bmRhcmQtQ2lwaGVyLWJhc2VkIE1lc3NhZ2UKICAgICAgICAgICAgICBBdXRoZW50aWNhdGlvbiBD b2RlLVBzZXVkby1SYW5kb20gRnVuY3Rpb24tMTI4IChBRVMtQ01BQy0KICAgICAgICAgICAgICBQ UkYtMTI4KSBBbGdvcml0aG0gZm9yIHRoZSBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgUHJvdG9jb2wK ICAgICAgICAgICAgICAoSUtFKSIsIFJGQyA0NjE1LCBBdWd1c3QgMjAwNi4KCgoKCgoKCgoKCgpM ZWJvdml0eiAmIFJlc2NvcmxhICAgICAgICBFeHBpcmVzIE1heSAxLCAyMDEwICAgICAgICAgICAg ICAgICBbUGFnZSAxN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQ3J5cHRvIGZvciBU Q1AtQU8gICAgICAgICAgICAgICBPY3RvYmVyIDIwMDkKCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAg IEdyZWdvcnkgTGVib3ZpdHoKICAgSnVuaXBlciBOZXR3b3JrcywgSW5jLgogICAxMTk0IE5vcnRo IE1hdGhpbGRhIEF2ZS4KICAgU3Vubnl2YWxlLCBDQSAgOTQwODktMTIwNgogICBVUwoKICAgUGhv bmU6CiAgIEVtYWlsOiBncmVnb3J5LmlldGZAZ21haWwuY29tCgoKICAgRXJpYyBSZXNjb3JsYQog ICBSVEZNLCBJbmMuCiAgIDIwNjQgRWRnZXdvb2QgRHJpdmUKICAgUGFsbyBBbHRvLCBDQSAgOTQz MDMKICAgVVMKCiAgIFBob25lOiA2NTAtNjc4LTIzNTAKICAgRW1haWw6IGVrckBydGZtLmNvbQoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTGVib3ZpdHogJiBSZXNjb3JsYSAgICAgICAg RXhwaXJlcyBNYXkgMSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMThdCgwKCg== --=====================_124683750==_-- From root@core3.amsl.com Wed Oct 28 09:15:02 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F08C73A691F; Wed, 28 Oct 2009 09:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091028161501.F08C73A691F@core3.amsl.com> Date: Wed, 28 Oct 2009 09:15:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-auth-opt-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : The TCP Authentication Option Author(s) : J. Touch, A. Mankin, R. Bonica Filename : draft-ietf-tcpm-tcp-auth-opt-08.txt Pages : 45 Date : 2009-10-28 This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either static master key tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses its own option identifier, even though used mutually exclusive of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-auth-opt-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-28090806.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Oct 28 10:45:02 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0983D28C0EA; Wed, 28 Oct 2009 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091028174502.0983D28C0EA@core3.amsl.com> Date: Wed, 28 Oct 2009 10:45:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-ao-crypto-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Cryptographic Algorithms for TCP's Authentication Option, TCP-AO Author(s) : G. Lebovitz, E. Rescorla Filename : draft-ietf-tcpm-tcp-ao-crypto-01.txt Pages : 18 Date : 2009-10-28 The TCP Authentication Option, TCP-AO, relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithm(s). This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-ao-crypto-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-ao-crypto-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-28103050.I-D@ietf.org> --NextPart-- From gregory.ietf@gmail.com Wed Oct 28 11:17:51 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586EE3A6A2E for ; Wed, 28 Oct 2009 11:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAgTICrbaa9P for ; Wed, 28 Oct 2009 11:17:50 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 42B1C3A6921 for ; Wed, 28 Oct 2009 11:17:50 -0700 (PDT) Received: by bwz23 with SMTP id 23so1326292bwz.29 for ; Wed, 28 Oct 2009 11:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:mime-version:content-type; bh=ZCz0HuB7V8j/1NjV3pleiMcYbfaI1Oj+2O82EmwW5pM=; b=FGiJk9JUoBrm25f+h2N5THE5PXjnLO3MljBiXEjeiXjtz995pPv+JsIiMM9fyZXxI+ 1L7q9PoTX2EN5kDM7KuV03Hu3MVoNiJKQqZ71EX1lD7Ew67CtwImd2JSMh/puwwYbAyU HHLoYCJbjLI6z2JANGzc5ZSZFRXLGt6CQpRU8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:mime-version:content-type; b=cYM4i5LkG9w9T6HEAnIOVhpQ97IC+ePiMtbzY/jmDrICgaqEUqdCzx8XDdTSmhaOs1 nB0QBzDIO3Iy5DhPnHvSLsishjcb4sJI/+xuXEji6y1BJ5KBrBOnl80B/RbHqxr459N3 zKTGSL6IO6Gh6Nx+BqR2z4fWEn502A1K9vGxQ= Received: by 10.204.162.143 with SMTP id v15mr3303430bkx.50.1256753881524; Wed, 28 Oct 2009 11:18:01 -0700 (PDT) Received: from Gregory-T60.gmail.com (c-98-248-97-91.hsd1.ca.comcast.net [98.248.97.91]) by mx.google.com with ESMTPS id z15sm2315972fkz.44.2009.10.28.11.17.59 (version=SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 11:18:00 -0700 (PDT) Message-ID: <4ae88ad8.0f345e0a.0b8e.ffffffe7@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 28 Oct 2009 11:17:56 -0700 To: tcpm@ietf.org From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [tcpm] draft-ietf-tcpm-tcp-ao-crypto-02 posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 18:17:51 -0000 Hey all, I just got word from the Secretariat that the draft was posted to the repository. Nice work with your super duper powers, Lars. ;-) Gregory. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m From root@core3.amsl.com Fri Oct 30 10:00:04 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3028D3A693F; Fri, 30 Oct 2009 10:00:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091030170004.3028D3A693F@core3.amsl.com> Date: Fri, 30 Oct 2009 10:00:04 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-early-rexmt-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 17:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Early Retransmit for TCP and SCTP Author(s) : M. Allman, K. Avrachenkov, U. Ayesta, E. Blanton, P. Hurtig Filename : draft-ietf-tcpm-early-rexmt-02.txt Pages : 12 Date : 2009-10-30 This document proposes a new mechanism for TCP and SCTP that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-early-rexmt-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-early-rexmt-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-30095524.I-D@ietf.org> --NextPart--