From nobody Sun Nov 1 10:02:28 2015 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C3C1B8A9B; Sun, 1 Nov 2015 10:02:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151101180225.18970.9411.idtracker@ietfa.amsl.com> Date: Sun, 01 Nov 2015 10:02:25 -0800 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-cammac-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 18:02:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : Kerberos Authorization Data Container Authenticated by Multiple MACs Authors : Simo Sorce Tom Yu Filename : draft-ietf-kitten-cammac-04.txt Pages : 10 Date : 2015-11-01 Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-cammac-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-cammac-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 18 16:20:51 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14B81B3992 for ; Wed, 18 Nov 2015 16:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb49Do0D2xPi for ; Wed, 18 Nov 2015 16:20:48 -0800 (PST) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A479F1B3544 for ; Wed, 18 Nov 2015 16:20:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 1F752E675 for ; Wed, 18 Nov 2015 19:20:45 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s57DtOlqZFuj for ; Wed, 18 Nov 2015 19:20:42 -0500 (EST) Received: from [192.168.1.180] (wsip-174-76-19-88.oc.oc.cox.net [174.76.19.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 5A6A3E5D9 for ; Wed, 18 Nov 2015 19:20:42 -0500 (EST) From: "Henry B (Hank) Hotz, CISSP" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 18 Nov 2015 16:20:41 -0800 To: "kitten@ietf.org " Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 00:20:49 -0000 It seems to be time to do housecleaning on algorithms selections. Is = anyone interested in adding a new enctype to Kerberos? Why (else)? Speaking strictly for myself, I=E2=80=99d like to see a = mandatory-to-implement enctype that shares *nothing* with the current = aes-sha1-hmac stuff. I=E2=80=99m speaking purely strategically and not = from any mathematical suspicion of weakness. If someone discovers = something fundamentally wrong with the math behind SHA1 or AES, then it = might take out SHA2 or Camellia as well. I have nothing specific against the =E2=80=9Csuite-B=E2=80=9D proposal, = but they=E2=80=99re not what I=E2=80=99d like to see. I assume the NSA = is too busy riding the =E2=80=9Cpost quantum=E2=80=9D horse away from = their DRBG fiasco to help finish it. Just to throw some straw (just straw, not an actual strawman) on the = table, how about something that uses one of the European stream cipher = finalists with SHA-3? -------- Finally, is anyone interested in doing a die-die-die draft for = triple-des, or rc4? Personal: hbhotz@oxy.edu Business: hhotz@securechannels.com From nobody Wed Nov 18 18:39:14 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78341B3BB0 for ; Wed, 18 Nov 2015 18:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuOdRCSZJKbc for ; Wed, 18 Nov 2015 18:39:12 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B571B3BAF for ; Wed, 18 Nov 2015 18:39:11 -0800 (PST) X-AuditID: 12074424-f79216d00000156e-4f-564d364d5ffb Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 3C.E6.05486.D463D465; Wed, 18 Nov 2015 21:39:09 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tAJ2d9WR013570; Wed, 18 Nov 2015 21:39:09 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAJ2d5TE026486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Nov 2015 21:39:08 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tAJ2d5OR009225; Wed, 18 Nov 2015 21:39:05 -0500 (EST) Date: Wed, 18 Nov 2015 21:39:05 -0500 (EST) From: Benjamin Kaduk To: "Henry B (Hank) Hotz, CISSP" In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1880486494-1447900745=:26829" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1vU18w0zuHTa2OLjvYUsFkc3r2Jx YPJYsuQnk8fWpr/MAUxRXDYpqTmZZalF+nYJXBnnV1xiKrjKX3H+5zKmBsYvPF2MnBwSAiYS z7a0skPYYhIX7q1n62Lk4hASWMwkMbf7AiuEs5FRYvH9B4wgVUICh5gkbqxJhUg0MEocu9rN BJJgEdCWeHN9JzOIzSagIjHzzUY2EFtEwFBi+sqJrCA2s4ClxN5FP4HqOTiEBZQlXnxTAglz ClhLnGrYwQYS5hVwlFjwKAlilZXE96uHwKaICuhIrN4/hQXE5hUQlDg58wkLxMRAiZvHVzBP YBSchSQ1C0kKwlaXaHxwlg3C1pa4f7ONbQEjyypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdc73c zBK91JTSTYygsGZ3UdnB2HxI6RCjAAejEg/vhlM+YUKsiWXFlbmHGCU5mJREeXvOAYX4kvJT KjMSizPii0pzUosPMUpwMCuJ8JZdAsrxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1OTS1I LYLJynBwKEnwupj6hgkJFqWmp1akZeaUIKSZODhBhvMADX9jAlTDW1yQmFucmQ6RP8WoKCXO +00dKCEAksgozYPrBaed3UyqrxjFgV4R5k0FWcEDTFlw3a+ABjMBDT7R4AkyuCQRISXVwMiz KuepwvxynYw+qYZHE95FzDZ+FZEumqz9Xz5sb/JyX4MQyaKmkt1z38bvurcu4PosxqiNhVcF j+rkS7xWPT/luYbIBDatGUYMTvvtGKVXH8oO50ucw9NxU3R/Y7Ko2LRH/sFfNs9931Ugnfmi d92NvLc/8rXvi7etNtBdX72Tyz/mIM8xDyWW4oxEQy3mouJEAIlbljcWAwAA Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 02:39:14 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1880486494-1447900745=:26829 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 18 Nov 2015, Henry B (Hank) Hotz, CISSP wrote: > It seems to be time to do housecleaning on algorithms selections. Is anyo= ne interested in adding a new enctype to Kerberos? > > Why (else)? Speaking strictly for myself, I=E2=80=99d like to see a > mandatory-to-implement enctype that shares *nothing* with the current > aes-sha1-hmac stuff. I=E2=80=99m speaking purely strategically and not fr= om any > mathematical suspicion of weakness. If someone discovers something > fundamentally wrong with the math behind SHA1 or AES, then it might take > out SHA2 or Camellia as well. > > I have nothing specific against the =E2=80=9Csuite-B=E2=80=9D proposal, b= ut they=E2=80=99re not > what I=E2=80=99d like to see. I assume the NSA is too busy riding the =E2= =80=9Cpost > quantum=E2=80=9D horse away from their DRBG fiasco to help finish it. > > Just to throw some straw (just straw, not an actual strawman) on the > table, how about something that uses one of the European stream cipher > finalists with SHA-3? I had heard mutterings elsewhere about a chacha20-poly1305 sort of thing, which seems potentially interesting to me. The real question is whether implementors would pick up such a thing, and whether we can get consensus for MTI. There are public commitments to funding at least one implementation of the aes-cts-hmac-sha2 proposal, but I don't think I've heard anything one way or the other about a completely novel enctype. > Finally, is anyone interested in doing a die-die-die draft for triple-des= , or rc4? There is already https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00 -Ben ---559023410-1880486494-1447900745=:26829-- From nobody Wed Nov 18 19:24:17 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259471B3C2E for ; Wed, 18 Nov 2015 19:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STqRCdcB38HP for ; Wed, 18 Nov 2015 19:24:14 -0800 (PST) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EB61B3C44 for ; Wed, 18 Nov 2015 19:24:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id DD0E7E650; Wed, 18 Nov 2015 22:24:09 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0BbIZQsaUsU; Wed, 18 Nov 2015 22:24:09 -0500 (EST) Received: from [192.168.1.180] (wsip-174-76-19-88.oc.oc.cox.net [174.76.19.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id E90C9E64B; Wed, 18 Nov 2015 22:24:08 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: Date: Wed, 18 Nov 2015 19:24:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <06824D7B-C3AF-4DD2-BD02-2C94EE0E0948@oxy.edu> References: To: Benjamin Kaduk X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 03:24:16 -0000 > On Nov 18, 2015, at 6:39 PM, Benjamin Kaduk wrote: >=20 > On Wed, 18 Nov 2015, Henry B (Hank) Hotz, CISSP wrote: >=20 >> It seems to be time to do housecleaning on algorithms selections. Is = anyone interested in adding a new enctype to Kerberos? >>=20 >> Why (else)? Speaking strictly for myself, I=E2=80=99d like to see a >> mandatory-to-implement enctype that shares *nothing* with the current >> aes-sha1-hmac stuff. I=E2=80=99m speaking purely strategically and = not from any >> mathematical suspicion of weakness. If someone discovers something >> fundamentally wrong with the math behind SHA1 or AES, then it might = take >> out SHA2 or Camellia as well. >>=20 >> I have nothing specific against the =E2=80=9Csuite-B=E2=80=9D = proposal, but they=E2=80=99re not >> what I=E2=80=99d like to see. I assume the NSA is too busy riding the = =E2=80=9Cpost >> quantum=E2=80=9D horse away from their DRBG fiasco to help finish it. >>=20 >> Just to throw some straw (just straw, not an actual strawman) on the >> table, how about something that uses one of the European stream = cipher >> finalists with SHA-3? >=20 > I had heard mutterings elsewhere about a chacha20-poly1305 sort of = thing, > which seems potentially interesting to me. The real question is = whether > implementors would pick up such a thing, and whether we can get = consensus > for MTI. >=20 > There are public commitments to funding at least one implementation of = the > aes-cts-hmac-sha2 proposal, but I don't think I've heard anything one = way > or the other about a completely novel enctype. It=E2=80=99s the difference between fixing known weaknesses and (trying) = to protect against unknown ones. >> Finally, is anyone interested in doing a die-die-die draft for = triple-des, or rc4? >=20 > There is already > = https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00 OK, love the name. ;-) On quick scan the content looks good too. I guess = I missed it because I didn=E2=80=99t have my current job yet, and my = life was a bit unstable. I=E2=80=99ll certainly put in a strong second as being supportive of = that draft (with TBD nits). However, as several have said on saag, we = need to make sure we have enough good algorithms available if we want to = depreciate algorithms. > -Ben Personal: hbhotz@oxy.edu Business: hhotz@securechannels.com From nobody Wed Nov 18 23:31:27 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAB41A90F1 for ; Wed, 18 Nov 2015 23:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFGBng23ruHF for ; Wed, 18 Nov 2015 23:30:23 -0800 (PST) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE771A90EE for ; Wed, 18 Nov 2015 23:30:22 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id jKWK1r00D10HQrX01KWL7A; Thu, 19 Nov 2015 08:30:20 +0100 Message-ID: <564D7A8A.2070208@openfortress.nl> Date: Thu, 19 Nov 2015 08:30:18 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Henry B (Hank) Hotz, CISSP" References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 07:30:26 -0000 Hello, > It seems to be time to do housecleaning on algorithms selections. Is > anyone interested in adding a new enctype to Kerberos? > One thing I would like to bring into any such discussion is that it would be possible to use through PKCS #11, the de-facto standard for storing keys on tokens, including hardware keys that will never share keys directly but allow their use through the API. This extends the range of possible uses for Kerberos, I think. For instance, AES-CTS-HMAC uses plain standard AES and HMAC, and CTS can be implemented in terms of standard CBC, so it ought to be possible to implement with PKCS #11 (not that I've already actually tried, but it looks possible). Of a similar stance, I've been wanting to see more Checksum Types, such as SHA256/384/512, for use with my TLS-KDH work. -Rick From nobody Thu Nov 19 22:04:42 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595FC1A9173 for ; Thu, 19 Nov 2015 22:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBhUsRlS5SJO for ; Thu, 19 Nov 2015 22:04:40 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id BF84C1A9171 for ; Thu, 19 Nov 2015 22:04:39 -0800 (PST) X-AuditID: 12074422-f79c46d000006aa7-98-564eb7f60bb5 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 55.F7.27303.6F7BE465; Fri, 20 Nov 2015 01:04:38 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tAK64cT7000580; Fri, 20 Nov 2015 01:04:38 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAK64Yfk029406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Nov 2015 01:04:37 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tAK64XBV008908; Fri, 20 Nov 2015 01:04:33 -0500 (EST) Date: Fri, 20 Nov 2015 01:04:33 -0500 (EST) From: Benjamin Kaduk To: Rick van Rein In-Reply-To: <564D7A8A.2070208@openfortress.nl> Message-ID: References: <564D7A8A.2070208@openfortress.nl> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrPttu1+YQftBK4ujm1exWDx9dY/N gcljyZKfTB4b/jWxBTBFcdmkpOZklqUW6dslcGXMfDqJreAdX8WSSX/ZGxg/cHcxcnJICJhI TL9wkA3CFpO4cG89kM3FISSwmEli28ebLBDORkaJ5xf+MkI4h5gk3nzthCprYJTY+vgtaxcj BweLgLbEl1NqIKPYBFQkZr7ZCDZWREBD4vOvqWA2s4ClxN5FP5lAyoUFlCVefFMCCXMK6Euc mXyFBcTmFXCUuLVwIyuILSQQK/Goq4sdxBYV0JFYvX8KVI2gxMmZT1ggRmpJLJ++jWUCo+As JKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrq5WaW6KWmlG5iBAUqu4vSDsafB5UO MQpwMCrx8N6Q9AsTYk0sK67MPcQoycGkJMprvgkoxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3 qR9QjjclsbIqtSgfJiXNwaIkzjv3i2+YkEB6YklqdmpqQWoRTFaGg0NJgnfLNqBGwaLU9NSK tMycEoQ0EwcnyHAeoOE3QGp4iwsSc4sz0yHypxgVpcR5p4MkBEASGaV5cL3gRLKbSfUVozjQ K8K8b0GqeIBJCK77FdBgJqDBv2t8QQaXJCKkpBoYBWU0+J5dOXeunve+eL/JSrfep42mv0tE VDbNtxd00Uuavmrm4TvTt3wRM+ndv2rmmi+6HjGGx0XlihJute6xff0sx/Dh4oC6J6+6D7XM m+0jeWtlSMT7hU8ceI9YNq3VV3mYZmi7UruflXMF5w6Fg1I3mRt3lNYuXq+e63NU/tVudkb7 xys7lFiKMxINtZiLihMBKRjOtf8CAAA= Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 06:04:41 -0000 On Thu, 19 Nov 2015, Rick van Rein wrote: > Hello, > > > It seems to be time to do housecleaning on algorithms selections. Is > > anyone interested in adding a new enctype to Kerberos? > > > One thing I would like to bring into any such discussion is that it > would be possible to use through PKCS #11, the de-facto standard for > storing keys on tokens, including hardware keys that will never share > keys directly but allow their use through the API. This extends the > range of possible uses for Kerberos, I think. It is probably premature to insist on this as a requirement, but it can certainly be a part of the discussion. > For instance, AES-CTS-HMAC uses plain standard AES and HMAC, and CTS can > be implemented in terms of standard CBC, so it ought to be possible to > implement with PKCS #11 (not that I've already actually tried, but it > looks possible). The argument would be more compelling if there was some prior art for it, though -- I don't know of any hardware devices implementing such a scheme at present. > Of a similar stance, I've been wanting to see more Checksum Types, such > as SHA256/384/512, for use with my TLS-KDH work. Registering a new Checksum type is not particularly difficult, but seeing that it gets implemented and used can be harder. The de facto state of affairs at present seems to be that Checksum types go hand-in-hand with encryption types, and the required checksum for a given encryption type is the only one ever used with it. There may not be full support for using a non-required checksum type with a given encryption type, but of course use of checksums outside of traditional encryption types will require new code anyway, so adding use of Checksums without encryption would not present additional implementation effort other than that needed to actually implement the new protocol feature. -Ben From nobody Thu Nov 19 22:24:07 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449EF1A8745 for ; Thu, 19 Nov 2015 22:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKtYdNSHM3Yp for ; Thu, 19 Nov 2015 22:24:04 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFCD1A7005 for ; Thu, 19 Nov 2015 22:24:04 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5D798284CD9; Fri, 20 Nov 2015 06:24:03 +0000 (UTC) Date: Fri, 20 Nov 2015 06:24:03 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20151120062402.GJ18315@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 06:24:06 -0000 On Wed, Nov 18, 2015 at 04:20:41PM -0800, Henry B (Hank) Hotz, CISSP wrote: > It seems to be time to do housecleaning on algorithms selections. Is anyone > interested in adding a new enctype to Kerberos? Yes, but see below. > Why (else)? Speaking strictly for myself, I�d like to see a > mandatory-to-implement enctype that shares *nothing* with the current > aes-sha1-hmac stuff. I�m speaking purely strategically and not from any > mathematical suspicion of weakness. If someone discovers something > fundamentally wrong with the math behind SHA1 or AES, then it might take > out SHA2 or Camellia as well. Sharing nothing is much too radical, unlikely to get much adoption. There is too much momentum behind AES (hardware support in modern CPUs, ...) and no substantive evidence of any real concerns (beyond the long-understood timing side-channel issues with naive software-only implementations). > Just to throw some straw (just straw, not an actual strawman) on the table, > how about something that uses one of the European stream cipher finalists > with SHA-3? As a backup, sure, but SHA-3 is quite slow, and has no hardware support. The throught of GSSAPI wrap is largely dominated by SHA-1 performance these days. We'd be much better off with OCB, or another AEAD mode. And we could use an updated set of AES enctypes, before jumping to more exotic stream ciphers. -- Viktor. From nobody Fri Nov 20 04:22:25 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F521B2F46 for ; Fri, 20 Nov 2015 04:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HguAV4pDb2cr for ; Fri, 20 Nov 2015 04:22:21 -0800 (PST) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967611B2F43 for ; Fri, 20 Nov 2015 04:22:20 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id joNF1r00U10HQrX01oNGuK; Fri, 20 Nov 2015 13:22:18 +0100 Message-ID: <564F1076.4030905@openfortress.nl> Date: Fri, 20 Nov 2015 13:22:14 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Benjamin Kaduk References: <564D7A8A.2070208@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 12:22:23 -0000 Hi, >> For instance, AES-CTS-HMAC uses plain standard AES and HMAC, and CTS can >> be implemented in terms of standard CBC, so it ought to be possible to >> implement with PKCS #11 (not that I've already actually tried, but it >> looks possible). > > The argument would be more compelling if there was some prior art for it, > though -- I don't know of any hardware devices implementing such a scheme > at present. Both AES and CBC are widely supported by PKCS #11 solutions, software and hardware. And CTS can be built on top of CBC, "from the outside" of the mode. But I do agree that at least a demo would be nice to have. Let's see if that drowns in my TODO pile. -Rick From nobody Fri Nov 20 09:57:12 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDF41B3AD0 for ; Fri, 20 Nov 2015 09:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V44oHIkqIsKR for ; Fri, 20 Nov 2015 09:57:09 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6D01B3ACD for ; Fri, 20 Nov 2015 09:57:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC757BE7B for ; Fri, 20 Nov 2015 17:57:07 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVA4B6NdBZ5L for ; Fri, 20 Nov 2015 17:57:07 +0000 (GMT) Received: from [10.87.48.95] (unknown [86.46.27.72]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3CCA4BE64 for ; Fri, 20 Nov 2015 17:57:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1448042227; bh=vFXk7lw12Z9ONwszeB58v2o6owCO7RZUgvyxMOe38IM=; h=To:From:Subject:Date:From; b=N0eqk36opkvaI+geDPAl7WLD1+TXnsrQqOBTemQGBJ549RTZw0Zhc0ieK9dchHvZy anUeoAJAU2bbVOuF/lgk+2EspCEjhb3jlaUjSKG2IW5fvG/LRAcmrhE2OFQSgSUnPD tYNC1PDANAftv54jeU1/YNKwoqrdTCbHKYEz+Pso= To: "kitten@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564F5EF1.7090602@cs.tcd.ie> Date: Fri, 20 Nov 2015 17:57:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [kitten] AD review of draft-ietf-kitten-rfc4402bis-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 17:57:11 -0000 I read it and have no comments as it seems fine. I've asked for IETF LC to be started. Cheers, S. From nobody Fri Nov 20 10:10:35 2015 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB491B3B36; Fri, 20 Nov 2015 10:10:33 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151120181033.11161.71941.idtracker@ietfa.amsl.com> Date: Fri, 20 Nov 2015 10:10:33 -0800 Archived-At: Cc: kitten@ietf.org, kitten-chairs@ietf.org, draft-ietf-kitten-rfc4402bis@ietf.org Subject: [kitten] Last Call: (A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism) to Proposed Standard X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 18:10:33 -0000 The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-12-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. This document obsoletes RFC 4402 and reclassifies that document as historic. RFC 4402 starts the PRF+ counter at 1, however a number of implementations starts the counter at 0. As a result, the original specification would not be interoperable with existing implementations. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc4402bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc4402bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Nov 20 11:05:21 2015 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD001B3D1A; Fri, 20 Nov 2015 11:05:18 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151120190518.8724.61700.idtracker@ietfa.amsl.com> Date: Fri, 20 Nov 2015 11:05:18 -0800 Archived-At: Cc: kitten@ietf.org, kitten-chairs@ietf.org, draft-ietf-kitten-cammac@ietf.org Subject: [kitten] Last Call: (Kerberos Authorization Data Container Authenticated by Multiple MACs) to Proposed Standard X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 19:05:18 -0000 The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'Kerberos Authorization Data Container Authenticated by Multiple MACs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-12-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/ballot/ No IPR declarations have been submitted directly on this I-D. This is a second last call for this document - an error was discovered when this was in the RFC editor queue, it was taken back to the WG and is now ready to jump all the hoops again. From nobody Sun Nov 22 12:18:08 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7991B345E for ; Sun, 22 Nov 2015 12:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XMrBhLtGQ4g for ; Sun, 22 Nov 2015 12:18:05 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23431B345D for ; Sun, 22 Nov 2015 12:18:04 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id kkJ01r00610HQrX01kJ1u1; Sun, 22 Nov 2015 21:18:02 +0100 Message-ID: <565222F6.6000103@openfortress.nl> Date: Sun, 22 Nov 2015 21:17:58 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Benjamin Kaduk References: <564D7A8A.2070208@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org " Subject: Re: [kitten] New EncTypes? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2015 20:18:07 -0000 Hello Benjamin, >> For instance, AES-CTS-HMAC [...] ought to be possible to >> implement with PKCS #11 (not that I've already actually tried, but it >> looks possible). > > The argument would be more compelling if there was some prior art for it, > though -- I don't know of any hardware devices implementing such a scheme > at present. I made a working demonstration that generates the test vectors for AES128-CTS based on PKCS #11 stored AES key, https://github.com/arpa2/kerberos-pkcs11 The demo comes to the boring conclusion that a diff between what it generates and what was stripped from the RFC is empty: shell> make gcc -ggdb3 -DDEBUG -I /usr/local/src/SoftHSMv2-with-OpenPGP/src/lib/cryptoki_compat/ -Wl,-rpath=/usr/local/src/SoftHSMv2-with-OpenPGP/src/lib/.libs /usr/local/src/SoftHSMv2-with-OpenPGP/src/lib/.libs/libsofthsm.so -o aes128-cts-pkcs11 aes128-cts-pkcs11.c ./aes128-cts-pkcs11 > output.txt Token PIN: sekreet diff -u testvectors.txt output.txt shell> I ran this against SoftHSMv2 from the OpenDNSSEC project, but there is no reason why it would not work on hardware tokens that implement the same API; it only relies on CKK_AES and CKM_AES_CBC, which are not special at all. Enjoy, -Rick From nobody Thu Nov 26 23:17:51 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC4D1B31BB for ; Thu, 26 Nov 2015 23:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.214 X-Spam-Level: X-Spam-Status: No, score=0.214 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0hwLZ2-OnPR for ; Thu, 26 Nov 2015 23:17:48 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3FA1B31B9 for ; Thu, 26 Nov 2015 23:17:48 -0800 (PST) Received: by us.padl.com with ESMTP id tAR7Hean024421; Fri, 27 Nov 2015 02:17:44 -0500 From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_2F25748D-E2A3-41A6-BB15-E51688512D9C" Message-Id: Date: Fri, 27 Nov 2015 18:17:38 +1100 To: "kitten@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Subject: [kitten] aes-cts-hmac-sha2 test vectors X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 07:17:50 -0000 --Apple-Mail=_2F25748D-E2A3-41A6-BB15-E51688512D9C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Is it possible to annotate the encryption test vectors with the base key? -- www.lukehoward.com soundcloud.com/lukehoward --Apple-Mail=_2F25748D-E2A3-41A6-BB15-E51688512D9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Is it possible to annotate the encryption test vectors with = the base key?

--
www.lukehoward.com
soundcloud.com/lukehoward
= --Apple-Mail=_2F25748D-E2A3-41A6-BB15-E51688512D9C-- From nobody Fri Nov 27 00:38:52 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AC41A010D for ; Fri, 27 Nov 2015 00:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5e0ZboVCPAR for ; Fri, 27 Nov 2015 00:38:50 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25941A1A1F for ; Fri, 27 Nov 2015 00:38:50 -0800 (PST) Received: by us.padl.com with ESMTP id tAR8cHNX027878; Fri, 27 Nov 2015 03:38:22 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_29888C96-30C2-4FD9-BFD7-986E65D127C3" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Luke Howard In-Reply-To: Date: Fri, 27 Nov 2015 19:38:15 +1100 Message-Id: <17899394-473D-457D-8248-2869824E8938@padl.com> References: To: "kitten@ietf.org" X-Mailer: Apple Mail (2.3096.5) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.9 Archived-At: Cc: mjjenki@tycho.ncsc.mil, kelley.burgin@gmail.com Subject: Re: [kitten] aes-cts-hmac-sha2 test vectors X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 08:38:52 -0000 --Apple-Mail=_29888C96-30C2-4FD9-BFD7-986E65D127C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ditto for PRF. I ask as some implementations don=E2=80=99t have an easy = way to feed in the pre-derived key. > On 27 Nov 2015, at 6:17 PM, Luke Howard wrote: >=20 > Is it possible to annotate the encryption test vectors with the base = key? >=20 > -- > www.lukehoward.com > soundcloud.com/lukehoward > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- www.lukehoward.com soundcloud.com/lukehoward --Apple-Mail=_29888C96-30C2-4FD9-BFD7-986E65D127C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ditto for PRF. I ask as some implementations don=E2=80=99t = have an easy way to feed in the pre-derived key.

On 27 Nov 2015, at 6:17 PM, Luke Howard <lukeh@padl.com> = wrote:

Is it possible = to annotate the encryption test vectors with the base key?

--
_________________________________= ______________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

--
www.lukehoward.com
soundcloud.com/lukehoward

= --Apple-Mail=_29888C96-30C2-4FD9-BFD7-986E65D127C3-- From nobody Fri Nov 27 07:49:34 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78DD1B32C2 for ; Fri, 27 Nov 2015 07:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdzbRA9afHFI for ; Fri, 27 Nov 2015 07:49:32 -0800 (PST) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4171B329F for ; Fri, 27 Nov 2015 07:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1448639350; x=1449244150; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:Cc:From:Openpgp:Organization:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type; bh=IXIxhS1jkn5 /1Jgquf/Z1jBgJ7I/BaSUzkR/bFyRdqg=; b=eDDvFCgNmS3xviRGojH047YJGeH kQ/94z3yjC1F/jw4yYFieFH/5yGOngnwnrM6MOvo2f/eebMbf+XTfw1Cc77u7R3p 1xRvCtrjHw0sUM29ngN+BIKAFQV6deodJKiXDxUwx+5WGMge9UpTisuPDXkT6J0E 1LWnnvc7pQeVPOfQ= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Fri, 27 Nov 2015 10:49:10 -0500 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Fri, 27 Nov 2015 10:49:09 -0500 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v15.5.2) with ESMTPSA id md50000992176.msg for ; Fri, 27 Nov 2015 10:49:09 -0500 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Fri, 27 Nov 2015 10:49:09 -0500 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=17731c4c21=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: Michael Peck , Michael Jenkins References: From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu X-Enigmail-Draft-Status: N1110 Organization: Secure Endpoints Inc. Message-ID: <56587B6E.3010303@secure-endpoints.com> Date: Fri, 27 Nov 2015 10:49:02 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000201070109060806050409" Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 15:49:34 -0000 This is a cryptographically signed message in MIME format. --------------ms000201070109060806050409 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/17/2015 5:23 PM, Benjamin Kaduk wrote: >=20 > That seems to leave us with the following action items: >=20 > For the document editor: > * remove truncation from the PRF output and use the natural hash output= > length > * remove the use of random-to-key() and discussion of constant values f= rom > section 3 > * add an output length argument to KDF-HMAC-SHA2() and adjust text > accordingly > * update test vectors to include base keys and key usage values for all= > test cases > * reword the text discussing aes256 with 192-bit keys Michael and Michael, How is draft-ietf-kitten-aes-cts-hmac-sha2-07 coming along? As promised, Luke Howard is implementing aes-cts-hmac-sha2 for Heimdal. Luke currently has -06 implemented and I would prefer to see a verified implementation of -07 with the above changes. Thank you. Jeffrey Altman --------------ms000201070109060806050409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DV0wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0GCSqGSIb3DQEBBQUAMIHKMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9y IGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGlj IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEwMDAwMDBa Fw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29y cG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMbsJ/0dY/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7s A8snm48ggDfg5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7Y I09IUSNqYISo7icvYN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVp cLSp5Fbp2x1c9KY24mu1Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0 d/nAoccOcu9m4uW5yuDzhXc1mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJA MDgGCCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWdu LmNvbTASBgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAm BggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoa aHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2Ny bC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNVHQ4EFgQUrfnDk3IttbkoYeSk 12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRp b24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IB AQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KW cFRwYk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aH maturZXBAD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt 1iqoyd7ZAAJP4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIHEzCCBfugAwIB AgIQQA2IH1dlro2ulxZcz+4MMjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAb BgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBO ZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFu dGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTQxMjE4MDAw MDAwWhcNMTUxMjE5MjM1OTU5WjCBzjEuMCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVk IC0gMTQxODg4MjEwMTAyMDErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5kcG9p bnRzLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYDVQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHTAbBgNVBAoMFFN5bWFudGVj IENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxnG6iSpLXZAJ fuf957V+eQY5l/8a4s+wvFslpyNyHmih3Y+GGv1YUhn8QYufFKOFe8FflVwDmyvhJC4Dv7dj nbVDsM9OEl/GUacmcb8OWJS+dInkUbZO0isRny1W8SVdaXxp0QemjNczsbhE73bImHJU3KES VyqDB5VJqwvn+Ixdm8bug0D1aHeR6NpCXOVYjtZm508+y9n7kVph/Wn0K2vEOlGiVpyR69WU qpFqY2tGthseOwvOQmH3wKE19fro7mMINCwPAt0S9BZxr2pR+HWpbH04KbJIRBlykaTDAJYv Dqu2zjm9aMc4jPfskefr99L2d+2nQtr8fC9ZuBe1lwIDAQABo4IDETCCAw0wDAYDVR0TAQH/ BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTNie4wJCrT/MLp/t7Oa7+9uxA5HjAnBgNVHREEIDAegRxqYWx0bWFuQHNl Y3VyZS1lbmRwb2ludHMuY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIB KwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlk dWFsJTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25h JTIwTm90JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIw TmV0d29yayUyQyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUy MCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6 Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4 MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUF BwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8v d3d3LnN5bWF1dGguY29tL3JwYTArBgpghkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGG x85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVj M2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQC2axIcwU2XW8yc5xHsZFr2JiLt QNrPAfeajH5NPGk74Ptw+hesFBnmVSf+8fL608SEPb72L3214wwXaVi51aFGnhDNov/9esdt TR6nwBcOarUscuGEAE7kCKnr5PeitryCI4y/76yMGXr8DwT6ZP14QCODH7s6PPW7k/qSQfaR FRPCAjVD1XbsnXGQCdEdJvKkFSLChGKgJFCw9VOj/DipfGpW5RhZBbqlyEj23jJYODgPDOQV eSMRyBn1J14Thx/wC9cRPRlbeA5hnfMvesvpYyR1f5g/dzbyWh9OFuqLpw2/EQVbfA0b6tDC x7VmqVB5Rt8x/IvyCfKfY0OV3ckRMYIEYjCCBF4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0w GwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1h bnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBADYgfV2Wuja6X FlzP7gwyMA0GCWCGSAFlAwQCAQUAoIICdzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNTExMjcxNTQ5MDJaMC8GCSqGSIb3DQEJBDEiBCCUJRvFxENunDhM LuA/BlKo9V3VXbhX72ITKPvX5FQl0TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYD VQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBA DYgfV2Wuja6XFlzP7gwyMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkGA1UEBhMCVVMx HTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVz dCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5 bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEANiB9XZa6N rpcWXM/uDDIwDQYJKoZIhvcNAQEBBQAEggEAGEDA4s12iib+TCYt6d1ku+MsMt/LWqaPpDST S5tINbpko9EoEXjag0EwHa57CPikHLN99ijsMjNKzFrGqxsFjMgrsP2FEJIrlofPwMKwI/JP oJN2N2gdzW82mCsDrqsd29Y6caMITUXt9jjXvvAwGd7M4vMGP/Xla7ws5vXk6GAncavvrrhk 6Gn0pwxyfR2agG6aT0CKZtSxlORqqA/NsuqnRENiRWYou/L5rQAl7j0cm+tUtW6J9ETrlXyX Pk7APac8Km+q9crqmCVMx+DYkkLHH+4KIRzTQ/AIKlY5+HLf/tqUzJlxk5JEgbVwUIEFru/j ZRUNiv7eiRBZemeUyQAAAAAAAA== --------------ms000201070109060806050409-- From nobody Fri Nov 27 12:27:38 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1CE1B2B8D for ; Fri, 27 Nov 2015 12:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3td6OlqE1XGD for ; Fri, 27 Nov 2015 12:27:36 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 355CE1B2B81 for ; Fri, 27 Nov 2015 12:27:36 -0800 (PST) Received: by vkha189 with SMTP id a189so73751156vkh.2 for ; Fri, 27 Nov 2015 12:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DPn/pamxvqSKnAAdT6vTljxNojBVlWq2WFc+BxmQHog=; b=WzbpxMcsjLsJtynzquvf9dJKysZPRLXxSXLQ9enbmmWuvoL+Ig9jYxtF8Y7+kFC3IV gUDZu4B0X8Yi5XGt/UGTjIgPmM5a8A1MXnchSEga4QJz/HHMQX/DHU5thBoDEhqnveMb YV5UNcH8IFdvS9ImFUqr20PR6RkVTPQPMMCFvWwzI38N2Axf09nv62PTfFKQ6bmGXmau l3VGVv9W0yTGu4E7psgk33VanVbxXSYN5NKwPFd0iKicYnVBB9sS5XKtpmhu59jU7Inm XOyMGE2xmi2+n3RQSShM4foc2wLzPY9E7Sc0sU6a8UdithP1Id4i9eGiqo8rVynuaK0c 3YbQ== MIME-Version: 1.0 X-Received: by 10.31.139.209 with SMTP id n200mr44091112vkd.93.1448656055118; Fri, 27 Nov 2015 12:27:35 -0800 (PST) Received: by 10.31.52.133 with HTTP; Fri, 27 Nov 2015 12:27:35 -0800 (PST) In-Reply-To: <56587B6E.3010303@secure-endpoints.com> References: <56587B6E.3010303@secure-endpoints.com> Date: Fri, 27 Nov 2015 15:27:35 -0500 Message-ID: From: Michael Jenkins To: Jeffrey Altman Content-Type: multipart/alternative; boundary=001a11458494912f5005258b8574 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 20:27:37 -0000 --001a11458494912f5005258b8574 Content-Type: text/plain; charset=UTF-8 We are working on the changes and will post a new draft as soon as possible! On Fri, Nov 27, 2015 at 10:49 AM, Jeffrey Altman < jaltman@secure-endpoints.com> wrote: > On 4/17/2015 5:23 PM, Benjamin Kaduk wrote: > > > > That seems to leave us with the following action items: > > > > For the document editor: > > * remove truncation from the PRF output and use the natural hash output > > length > > * remove the use of random-to-key() and discussion of constant values > from > > section 3 > > * add an output length argument to KDF-HMAC-SHA2() and adjust text > > accordingly > > * update test vectors to include base keys and key usage values for all > > test cases > > * reword the text discussing aes256 with 192-bit keys > > Michael and Michael, > > How is draft-ietf-kitten-aes-cts-hmac-sha2-07 coming along? > > As promised, Luke Howard is implementing aes-cts-hmac-sha2 for Heimdal. > Luke currently has -06 implemented and I would prefer to see a verified > implementation of -07 with the above changes. > > Thank you. > > Jeffrey Altman > > > > > -- Mike Jenkins mjjenki@tycho.ncsc.mil - if you want me to read it only at my desk m.jenkins.364706@gmail.com - to read everywhere 443-634-3951 --001a11458494912f5005258b8574 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We are working on the changes and will post a new draft as= soon as possible!

On Fri, Nov 27, 2015 at 10:49 AM, Jeffrey Altman &= lt;jaltma= n@secure-endpoints.com> wrote:
On 4/17/2015 5:23 PM, Benjamin Kaduk wrote:
>
> That seems to leave us with the following action items:
>
> For the document editor:
> * remove truncation from the PRF output and use the natural hash outpu= t
> length
> * remove the use of random-to-key() and discussion of constant values = from
> section 3
> * add an output length argument to KDF-HMAC-SHA2() and adjust text
> accordingly
> * update test vectors to include base keys and key usage values for al= l
> test cases
> * reword the text discussing aes256 with 192-bit keys

Michael and Michael,

How is draft-ietf-kitten-aes-cts-hmac-sha2-07 coming along?

As promised, Luke Howard is implementing aes-cts-hmac-sha2 for Heimdal.
=C2=A0Luke currently has -06 implemented and I would prefer to see a verifi= ed
implementation of -07 with the above changes.

Thank you.

Jeffrey Altman







--
Mik= e Jenkins
mjjenki@tycho.ncsc.mil - if you want me to read it only at my desk
m.j= enkins.364706@gmail.com - to read everywhere
443-634-3951
--001a11458494912f5005258b8574-- From nobody Fri Nov 27 16:34:49 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1641B2CF3 for ; Fri, 27 Nov 2015 16:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrCMxk5PJ5yv for ; Fri, 27 Nov 2015 16:34:47 -0800 (PST) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A351B2CF1 for ; Fri, 27 Nov 2015 16:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1448670864; x=1449275664; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:Cc:From:Openpgp:Organization:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type; bh=+QA+3Q2+p7n 5+aOmbTsBzzXkj2/TdXkUUMabe8qJ72Y=; b=kOcNrObxpOkqqIrnzugVEHw+Jop J5BSGyB5IM2Sh69qVguV88oXTIzIhFX5kpm1nmBWSLaSuC8sBARkp9dKcJUNj4Wa ScpdEfC8YUnh2o7nFb9qgUEFHAiaOIwKy8fkvqKZHrYelJoFlV5OycntCSCXf20f KrT1Ae4pse/AmSdI= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Fri, 27 Nov 2015 19:34:24 -0500 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Fri, 27 Nov 2015 19:34:24 -0500 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v15.5.2) with ESMTPSA id md50000992363.msg for ; Fri, 27 Nov 2015 19:34:23 -0500 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Fri, 27 Nov 2015 19:34:23 -0500 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1774e415d2=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: Michael Jenkins References: <56587B6E.3010303@secure-endpoints.com> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <5658F68B.8030300@secure-endpoints.com> Date: Fri, 27 Nov 2015 19:34:19 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020300030005060200010006" Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 00:34:48 -0000 This is a cryptographically signed message in MIME format. --------------ms020300030005060200010006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/27/2015 3:27 PM, Michael Jenkins wrote: > We are working on the changes and will post a new draft as soon as poss= ible! Luke Howard's implementation for Heimdal can be found at https://github.com/heimdal/heimdal/commits/lukeh/aes-cts-hmac-sha2 Jeffrey Altman --------------ms020300030005060200010006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DV0wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0GCSqGSIb3DQEBBQUAMIHKMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9y IGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGlj IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEwMDAwMDBa Fw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29y cG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMbsJ/0dY/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7s A8snm48ggDfg5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7Y I09IUSNqYISo7icvYN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVp cLSp5Fbp2x1c9KY24mu1Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0 d/nAoccOcu9m4uW5yuDzhXc1mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJA MDgGCCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWdu LmNvbTASBgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAm BggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoa aHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2Ny bC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNVHQ4EFgQUrfnDk3IttbkoYeSk 12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYD VQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRp b24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IB AQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KW cFRwYk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aH maturZXBAD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt 1iqoyd7ZAAJP4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIHEzCCBfugAwIB AgIQQA2IH1dlro2ulxZcz+4MMjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAb BgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBO ZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFu dGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTQxMjE4MDAw MDAwWhcNMTUxMjE5MjM1OTU5WjCBzjEuMCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVk IC0gMTQxODg4MjEwMTAyMDErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5kcG9p bnRzLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYDVQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHTAbBgNVBAoMFFN5bWFudGVj IENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxnG6iSpLXZAJ fuf957V+eQY5l/8a4s+wvFslpyNyHmih3Y+GGv1YUhn8QYufFKOFe8FflVwDmyvhJC4Dv7dj nbVDsM9OEl/GUacmcb8OWJS+dInkUbZO0isRny1W8SVdaXxp0QemjNczsbhE73bImHJU3KES VyqDB5VJqwvn+Ixdm8bug0D1aHeR6NpCXOVYjtZm508+y9n7kVph/Wn0K2vEOlGiVpyR69WU qpFqY2tGthseOwvOQmH3wKE19fro7mMINCwPAt0S9BZxr2pR+HWpbH04KbJIRBlykaTDAJYv Dqu2zjm9aMc4jPfskefr99L2d+2nQtr8fC9ZuBe1lwIDAQABo4IDETCCAw0wDAYDVR0TAQH/ BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTNie4wJCrT/MLp/t7Oa7+9uxA5HjAnBgNVHREEIDAegRxqYWx0bWFuQHNl Y3VyZS1lbmRwb2ludHMuY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIB KwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlk dWFsJTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25h JTIwTm90JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIw TmV0d29yayUyQyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUy MCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6 Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4 MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUF BwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8v d3d3LnN5bWF1dGguY29tL3JwYTArBgpghkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGG x85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVj M2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQC2axIcwU2XW8yc5xHsZFr2JiLt QNrPAfeajH5NPGk74Ptw+hesFBnmVSf+8fL608SEPb72L3214wwXaVi51aFGnhDNov/9esdt TR6nwBcOarUscuGEAE7kCKnr5PeitryCI4y/76yMGXr8DwT6ZP14QCODH7s6PPW7k/qSQfaR FRPCAjVD1XbsnXGQCdEdJvKkFSLChGKgJFCw9VOj/DipfGpW5RhZBbqlyEj23jJYODgPDOQV eSMRyBn1J14Thx/wC9cRPRlbeA5hnfMvesvpYyR1f5g/dzbyWh9OFuqLpw2/EQVbfA0b6tDC x7VmqVB5Rt8x/IvyCfKfY0OV3ckRMYIEYjCCBF4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0w GwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1h bnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBADYgfV2Wuja6X FlzP7gwyMA0GCWCGSAFlAwQCAQUAoIICdzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNTExMjgwMDM0MTlaMC8GCSqGSIb3DQEJBDEiBCCN4OxlJVLWYiW2 m7yfEc2O82ICdXZg9ViguKv2Y2RCdzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYD VQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBA DYgfV2Wuja6XFlzP7gwyMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkGA1UEBhMCVVMx HTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVz dCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5 bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEANiB9XZa6N rpcWXM/uDDIwDQYJKoZIhvcNAQEBBQAEggEAW/29NXwMboYN3pfrGIUvhTXmbqHOZSepTBlU 45c2dUzTPhHP/ZYlwM/OmDlB5P8uW2ldoRc4RT7bgbdle8raEZmkL17Hrq/582Ksp7BT70ID 3ai9WTcrE2PcbR/io1/Qw99l1Z4S0Po/gWSH0up+wF6VFdlYhlJP+WJU/37upaRjo0GgvMSf 92RBhSl/oyud1R9Gd+8k+NCgn68Gt/16cPJW0/vIqd0FTPdYHH6dptEtzIuCWfnZk9yznt2L 4orpeUff4fBNFB+V2mDopoh0RxqF1pG5AJqOxIjGWxtPZy1hQ20FUelbOQR2ZbDCYMLebdZW 45LqQ3hkFuOKlKVzmAAAAAAAAA== --------------ms020300030005060200010006--