[18839] in Kerberos_V5_Development
Re: [kitten] Verified authorization data
daemon@ATHENA.MIT.EDU (Peter Mogensen)
Thu Jun 12 09:38:27 2014
Message-ID: <5399AD46.4020805@one.com>
Date: Thu, 12 Jun 2014 15:38:14 +0200
From: Peter Mogensen <apm@one.com>
MIME-Version: 1.0
To: Simo Sorce <simo@redhat.com>
In-Reply-To: <1402579405.22737.37.camel@willson.usersys.redhat.com>
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 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.
/Peter
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
