[19615] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Tangent from: [kitten] Checking the transited list . . .

daemon@ATHENA.MIT.EDU (Henry B (Hank) Hotz, CISSP)
Mon Aug 21 14:03:02 2017

Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "Henry B (Hank) Hotz, CISSP" <hbhotz@oxy.edu>
In-Reply-To: <649fa812-aacf-80b6-1976-a719eca60fc2@mit.edu>
Date: Mon, 21 Aug 2017 11:02:37 -0700
Message-Id: <F5A25DBF-476A-462D-A7F1-C901BFC069D6@oxy.edu>
To: Greg Hudson <ghudson@mit.edu>
Cc: "kitten@ietf.org" <kitten@ietf.org>, heimdal-discuss@h5l.org,
        Samba Technical <samba-technical@lists.samba.org>,
        "krbdev@mit.edu Dev List" <krbdev@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit


> On Aug 21, 2017, at 7:05 AM, Greg Hudson <ghudson@mit.edu> wrote:
> 
> I'm not sure about "any KDC in the trust chain trusts the next hop."
> RFC 4120 doesn't think about cross-realm relationships in terms of
> trust.  Simply having cross-realm keys with another realm doesn't
> necessarily imply that the other realm is trustworthy.

That’s always been a slippery distinction in practice. Trust depends on “local policy” which may be determined by many things that are orthogonal to what the crypto can actually provide. Unless you’re writing the code yourself, I would presume that anything with an exchanged set of keys is trusted for authentication. Authorization is, of course, outside the scope of Kerberos.

Personal email.  hbhotz@oxy.edu




_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev


home help back first fref pref prev next nref lref last post