Re: Federated realms and PAD

>>>>> "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.

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

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



    >> 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.
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.

    Simo> Simo.

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


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