Re: [kitten] Verified authorization data

Simo Sorce <simo@redhat.com> Thu, 12 June 2014 13:50 UTC

Return-Path: <simo@redhat.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 9D8891B2A3B for <kitten@ietfa.amsl.com>; Thu, 12 Jun 2014 06:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level:
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 oo8dkCR6S3lY for <kitten@ietfa.amsl.com>; Thu, 12 Jun 2014 06:50:06 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id C8FBD1A00D5 for <kitten@ietf.org>; Thu, 12 Jun 2014 06:50:06 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5CDo6RS005771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Jun 2014 09:50:06 -0400
Received: from [10.3.113.187] (ovpn-113-187.phx2.redhat.com [10.3.113.187]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5CDo4e2021589; Thu, 12 Jun 2014 09:50:05 -0400
Message-ID: <1402581004.22737.39.camel@willson.usersys.redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Peter Mogensen <apm@one.com>
Date: Thu, 12 Jun 2014 09:50:04 -0400
In-Reply-To: <5399AD46.4020805@one.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> <5399A8F9.50609@one.com> <1402579405.22737.37.camel@willson.usersys.redhat.com> <5399AD46.4020805@one.com>
Organization: Red Hat, Inc.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/b6Wuvxj_zX9skMYsiZBvVLo1TNw
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:50:09 -0000

On Thu, 2014-06-12 at 15:38 +0200, Peter Mogensen wrote:
> On 2014-06-12 15:23, Simo Sorce wrote:
> > The idea is to compute MAC on:
> >
> > 1) EncTicketPart w/o any Authorization Data (otherwise chicken-egg as
> > you are still computing AD data, CAMMAC is AD data itself)
> > +
> > 2) AD Data contained in CAMMAC (we want to protect data within the
> > CAMMAC, anything outside of it is not our business).
> >
> > Makes sense ?
> 
> Yes. And that's also the way I've read the draft and which is the basis 
> for what I wrote.
> 
> So, do you agree that the chicken-egg problem in 1) would also have been 
> solved if the kdc-verifier were placed in the ticket outside of the 
> EncTicketPart?
> 
> Are you saying that computing EncTicketPart w/o any Authorization Data + 
> computing the final EncTicketPart is simpler than just computing the 
> final EncTicketPart?
> 
> And is it correct that even though AD not in the CAMMAC is not our 
> business it doesn't make much difference whether it's included in the 
> kdc-verifier, since it can only be verified having that specific ticket 
> anyway?
> 
> In an ideal world I would have considered placing the kdc-verifier 
> outside of EncTicketPart more intutive.
> 
> Anyway... I guess my primary grief is not the kdc-verifier, but the 
> svc-verifier and that just adding a small piece of data in AD-CAMMAC to 
> a ticket will increase its size from 400-500 bytes (AFAIR) to >600. 
> About 20%. That's a problem if you try to squeeze several tickets into 1 
> IP packet. ... and it seems like only necessary because of the rule that 
> the client can add anything to authorization-data. Otherwise the data 
> would already have been protected by the service-key once.

We have to work within the framework of RFC 4120 I am afraid, so it is
what it is.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York