Re: [kitten] Verified authorization data

Peter Mogensen <apm@one.com> Thu, 12 June 2014 13:19 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 9C3101B2A17 for <kitten@ietfa.amsl.com>; Thu, 12 Jun 2014 06:19:57 -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 d-68aLxS5Su4 for <kitten@ietfa.amsl.com>; Thu, 12 Jun 2014 06:19:56 -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 D55851B2A16 for <kitten@ietf.org>; Thu, 12 Jun 2014 06:19:55 -0700 (PDT)
Received: from [192.168.4.228] (unknown [92.246.16.62]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by officesmtp2.one.com (Postfix) with ESMTPSA id DDE23801173A3; Thu, 12 Jun 2014 13:19:53 +0000 (UTC)
Message-ID: <5399A8F9.50609@one.com>
Date: Thu, 12 Jun 2014 15:19:53 +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> <53988BB6.8010409@one.com> <1402506490.13617.9.camel@willson.usersys.redhat.com> <539952CC.8020703@one.com> <1402577232.22737.26.camel@willson.usersys.redhat.com> <5399A341.3070104@one.com> <1402578060.22737.30.camel@willson.usersys.redhat.com>
In-Reply-To: <1402578060.22737.30.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/ebSpxZaM8qysGLZlkKYhf8i0JaU
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: Thu, 12 Jun 2014 13:19:57 -0000

On 2014-06-12 15:01, Simo Sorce wrote:
> Yes, we decided to combine this protection with ticket binding in one
> single operation by using EncTicketPart in the MAC calculation, makign
> the CAMMAC *simpler* to build.

I must have misunderstood something fundamental then.

The draft says:
"the KDC computes the MAC in the kdc-
       verifier over the ASN.1 DER encoding of the EncTicketPart of the
       surrounding ticket, *but* where the AuthorizationData value in the
       EncTicketPart contains the AuthorizationData value contained in
       the CAMMAC instead of the AuthorizationData value that would
       otherwise be present in the ticket."

(My emphasis)

So it's not the actual EncTicketPart which is used for the MAC. It's 
another version with different AuthorizationData. You have to compute 
both versions.
Compared to simply just placing the kdc-verifier outside of the 
EncTicketPart and using the actual EncTicketPart for computing the MAC.
... which I know can give compatability problems, but just so we 
understand what each other is talking about.

I would intuitively think it was simpler to just sign the entire actual 
EncTicketPart with the kdc-verifier. Of course, that will then bind to 
also any other authdata in the ticket.

/Peter