[18840] in Kerberos_V5_Development
Re: [kitten] Verified authorization data
daemon@ATHENA.MIT.EDU (Simo Sorce)
Thu Jun 12 09:50:21 2014
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>
Mime-Version: 1.0
Cc: "kitten@ietf.org" <kitten@ietf.org>, "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
