IETF Logo Mail Archive

Re: [kitten] Verified authorization data

Peter Mogensen <apm@one.com> Wed, 11 June 2014 17:03 UTC

Return-Path: <apm@one.com>
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 8AF291A01CE for <kitten@ietfa.amsl.com>; Wed, 11 Jun 2014 10:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 MANsdRQpZ4Bv for <kitten@ietfa.amsl.com>; Wed, 11 Jun 2014 10:03:13 -0700 (PDT)
Received: from officesmtp2.one.com (officesmtp2.one.com [195.47.247.17]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BA91A01B7 for <kitten@ietf.org>; Wed, 11 Jun 2014 10:03:13 -0700 (PDT)
Received: from [10.163.144.45] (unknown [80.62.117.45]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by officesmtp2.one.com (Postfix) with ESMTPSA id 42951801173A3; Wed, 11 Jun 2014 17:03:06 +0000 (UTC)
Message-ID: <53988BB6.8010409@one.com>
Date: Wed, 11 Jun 2014 19:02:46 +0200
From: Peter Mogensen <apm@one.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Simo Sorce <simo@redhat.com>
References: <8D5F7E3237B3ED47B84CF187BB17B666118D870F@SHSMSX103.ccr.corp.intel.com> <5397328E.6020005@mit.edu> <539849AA.4000506@one.com> <1402503444.13617.1.camel@willson.usersys.redhat.com>
In-Reply-To: <1402503444.13617.1.camel@willson.usersys.redhat.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/fGY6HtjqJWzbNQgFOYH-rdKl5Yc
Cc: "kitten@ietf.org" <kitten@ietf.org>, "krbdev@mit.edu" <krbdev@MIT.EDU>
Subject: Re: [kitten] Verified authorization data
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Jun 2014 17:03:15 -0000

On 2014-06-11 18:17, Simo Sorce wrote:
> On Wed, 2014-06-11 at 14:20 +0200, Peter Mogensen wrote:
>> The solution in AD-CAMMAC seems very complex too, requiring
>> effectively calculating the entire EncTicketPart twice - and once for
>> every present AD-CAMMAC present.
>
> I am confused about this statement. The AD-CAMMAC draft specifies that
> it contains a sequence of AD elements, that means you have only 1
> AD-CAMMAC for all the AD data you want to protect. You check the whole
> thing only once.


I were not sure whether you could rule out any use case requiring 
merging of 2 AD-CAMMAC elements with - say - different other-verifier 
checksums for which the KDC didn't have all the keys.
But I guess that since other-verifier restricts the principals to be in 
the KDC realm, that could not happen.

Still... the whole EncTicketPart has to be constructed and DER-encoded 
twice to add a kdc-verifier.

/Peter

v2.30.2 | Report a Bug | By Email | System Status