Re: Federated realms and PAD

>>>>> "Simo" == Simo Sorce <[email protected]> writes:

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

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

I think making statements like "your own realm KDC trusts," illustrates
my point.
having one realm "trust" another is just not how you think in a
federated context.
You trust another realm to make statements within a limited context in a
federated context.
But people thinking about implementing and extending Kerberos are very
willing to make statements like "realm a trusts realm b,.

I'm very confident that you're not interested in spending the time to
refine the specification of the PAD to make it clear what fine-grained
trust assumptions are involved and to make your identifier choice etc
compatible with this.
So, I think we should say the PAD is not intended as a federated access
management tool but instead is a lot closer to the AD trust model.
You can import federated information into such a context, but you have
to do all the vetting at the point of import.

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

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

Deployment assumption not an implementation assumption.
To be clear, I think there's nothing prior to the PAD in the Kerberos
specifications that cannot be federated.
There is a lot in implementations and deployments.
    >> 
    >> 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.

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

The issue for a federated context is that there are a lot of identifiers
I can only filter by knowing what the exact values are.
They are not hierarchically filterable.
That makes federation really tricky.
So, yes I have things like the dns-domain.
That's fine.
But I have short identifiers convenient for hashing and storing on disk.
The PAD needs them, but they suck for federation because there's no good
way to set up reasonable filters for inter-federation.
If some federation member suddenly wants to claim some UUID or the like,
how do I know they've newly minted it, rather than picking a UUId that's
been in long use by someone not yet in the federation.

Even having the mechanisms necessary to make sure that one UUID claimed
by someone does not conflict with a UUID used by someone else in the
federation in a manner that is security-sensitive is tricky.
I think Project Moonshot is developing mechanisms good enough to at
least detect the conflicts, but such mechanisms are not deployed today.


    >> 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> I think we disagree 100% on this point unfortunately.  I see
    Simo> no point in having different AD numbers for something that has
    Simo> to be vetted by your own realm KDC anyway.

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

I'm fine using the same ad-type numbers for any case where that's the
client and cross-realm behavior you want.
remember that a KDC is a client of a PAD when issuing a new ticket.
I'm even OK with the same ad-type when you expect the KDC to apply some
filtering and to make a decision about whether to pass along a PAD to
the sorts of levels we're likely to implement.

However that's not a federation-friendly trust model.

When you start talking about things that are mostly filtered with some
few values getting through, or when you start talking about rigorous
federation-level filtering to allow mutually distrusting parties to send
a lot of attributes across without stepping on each others' toes you're
talking about federation. That will require different processing rules
and thus should have a different ad-type.
It's even more true when you want services to be suspicious of the attributes.
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg