Re: Federated realms and PAD

On Thu, 2012-02-16 at 10:09 -0500, Sam Hartman wrote:
> >>>>> "Simo" == Simo Sorce <[email protected]> writes:
> 
>     Simo> On Thu, 2012-02-16 at 08:36 -0500, Sam Hartman wrote:
>     >> >>>>> "Nico" == Nico Williams <[email protected]> writes:
>     >> 
>     Nico> so that it can get backed into scripts (I know, use $HOME).
>     Nico> And if we could rely on a global namespace, then I'd just drop
>     Nico> the URI thing.  But I don't think we can, not in federated
>     Nico> realms that aren't remotely in the same "administrative
>     Nico> domain", which I thought was part of what the PAD was all
>     Nico> about.
>     >> 
>     >> 
>     >> So, I've been thinking about federated contexts a lot lately
>     >> mostly for ABFAB but certainly beyond that.  When I explain why
>     >> Kerberos is not federated, one of the biggest things I cite is
>     >> that Kerberos has assumptions that bind it within one
>     >> organization.
> 
>     Simo> Do you have a write-up of what these assumptions are ?
> 
> No, but here are some:
> 
> 1) You can trust whatever the KDC says. IN a federated context, elements
> may forward you things that are not fully trusted, and you need to
> figure out how much you want to trust them.
> While possible in Kerberos this is not normally how people think.

When you say "the KDC" you mean your own Realm KDC, or do you include
"any KDC your Realm's KDC trusts" ?

> 2) The ability to authenticate implies something about how trusted you
> are. That is people grant access to all authenticated users to some
> resources.

This is sort-of true, but it is not a problem inherent in Kerberos, it
is an implementation issue. In fact we do have anonymous tickets now,
and they already break this assumption within a single realm.
I would characterize this as an implementation consideration (that may
make federation problematic) but not an assumption.

> 3) Identifiers are not always globally unique and relatively easy to
> verify in some hierarchical manner.

I would characterize this also as an implementation "issue" rather than
an assumption.

>     >> It's my understanding that the PAD has a very permissive trust
>     >> model. Obviously we haven't written it down yet, so this is still
>     >> open.  However, it doesn't sound to me like the PAD intends to
>     >> embrace federated cross-organizational contexts.  So, I think we
>     >> can assume a high degree of trust between PAD producers and
>     >> consumers.  That probably influences some of these discussions
>     >> somewhat.
> 
>     Simo> I am not sure the PAD itself is anything for/against federated
>     Simo> cross-organizational contexts. It is a matter of how much
>     Simo> code/policy decisions you want to put in your KDC filters. I
>     Simo> think you could use the PAD in a federated scenario, but int
>     Simo> that case you may end up generating on the KDC (or a dedicated
>     Simo> service the KDC has access to) most of the contents of the PAD
>     Simo> when the cross realm TGS is used and a ticket is requested.
> 
> I don't think I'm going to be comfortable with a trust model that
> vague--vague enough to permit both a federated and internal context.  I
> agree with you that you could have something PAD-like--possibly even the
> same data structure that was intended to be filtered heavily enough to
> be used in a federated context.  I'd expect you to consider something
> more heirarchical as a unique identifier for domains to make filtering
> easier and stuff like that.

You can use the DNS Domain name to do that. You have it.

> However even if was exactly the same encoding I'd expect the federated
> context PAD to have a different ad-type number than the internal context
> PAD.
> Why? In part because I'd expect applications to make different
> assumptions about it.

I think we disagree 100% on this point unfortunately.
I see no point in having different AD numbers for something that has to
be vetted by your own realm KDC anyway.

My intent is that once your KDC signs the PAD that clients in the realm
can fully trust what's in it. If you can't then you can never trust the
PAD at all.

Simo.

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

_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg