IETF Logo Mail Archive

Re: [kitten] New EncTypes?

Rick van Rein <rick@openfortress.nl> Thu, 19 November 2015 07:30 UTC

Return-Path: <rick@openfortress.nl>
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 <kitten@ietfa.amsl.com>; 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 <kitten@ietfa.amsl.com>; 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 <kitten@ietf.org>; 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 <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "Henry B (Hank) Hotz, CISSP" <hbhotz@oxy.edu>
References: <FEF7E228-3AF4-4D12-B4B0-CFB935B5ABB5@oxy.edu>
In-Reply-To: <FEF7E228-3AF4-4D12-B4B0-CFB935B5ABB5@oxy.edu>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/G-PXqjx8ACfTnscfg44Ay3vF7NY>
Cc: "kitten@ietf.org <kitten@ietf.org>" <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 <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=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

v2.23.0 | Report a Bug | By Email