[18826] in Kerberos_V5_Development
Re: [kitten] Verified authorization data
daemon@ATHENA.MIT.EDU (Simo Sorce)
Wed Jun 11 13:08:23 2014
Message-ID: <1402506490.13617.9.camel@willson.usersys.redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Peter Mogensen <apm@one.com>
Date: Wed, 11 Jun 2014 13:08:10 -0400
In-Reply-To: <53988BB6.8010409@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 Wed, 2014-06-11 at 19:02 +0200, Peter Mogensen wrote:
> 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.
That is done to bind the CAMMAC to a specific ticket, it is an
additional protection that you probably want for your use case too.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
