Re: Federated realms and PAD

On Thu, 2012-02-16 at 11:32 -0500, Sam Hartman wrote:
> >>>>> "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.

Please enlighten me.

> You trust another realm to make statements within a limited context in a
> federated context.

I do not see how my statement conflict with this, I think you may be
reading too much in it.

> But people thinking about implementing and extending Kerberos are very
> willing to make statements like "realm a trusts realm b,.

Well that's just a useful simplification I do not see that statement to
conflict with federation in any significant way.

I consider cross-realm trust to have the same issues any federate
environment has.

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

I think I am if the alternative is to reduce the utility of the PAD.

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

I am very against that. I see no reason why we should prevent usage of
the PAD in a federated environment.
Deployments may choose not to use it, or do heavy filtering or ... they
will do it anyway if they want to do so. So hiding behind a finger and
not addressing issue (if there are any) doesn't look like the right
thing to do to me.

> You can import federated information into such a context, but you have
> to do all the vetting at the point of import.

And this is "against" federation how ?

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

I do not see why the PAD cannot be federated. I do not understand why
you think that either yet.

> There is a lot in implementations and deployments.

... and life, and the universe and all :-)

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

You are not required to provide a short identifier, and if needed your
implementation can assign one at the entry point as all PADs go through
your KDC first.

> The PAD needs them, but they suck for federation because there's no good
> way to set up reasonable filters for inter-federation.

I do not understand this statement at all.

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

You don't, but you can track conflicts. The UDID is not a magic bullet,
you always need to be prepared to filter it even within trusted realms
that belong to the same organization because you could be very unlucky
and find out 2 realms you own turn up to have the same UDID internally.
That is a very rare event but you need to be able to handle it. (Even
just by filtering the PAD out entirely and logging the reason so that
admins can handle it by solving the problem elsewhere).

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

You are free to filter out everything, security is tricky, federation or
non-federation. I do not yet see any reason why you would use different
ADs to convey exactly the same information. Looks to me you are just
time-shifting the problem while at the same time make implementers life
more difficult, as now we have to care about 2 or more AD's to care
about.

Moreover it seem to me that the problems you see are mostly within the
filtering semantics that will be required and not much with the contents
of the PAD (please correct me if I am wrong here, because this is
critical) so if you just want to delay thinking about "federation"*
issues than maybe we can just say so in the RFC and defer to "additional
filtering considerations" to a later informational RFC.

> I think Project Moonshot is developing mechanisms good enough to at
> least detect the conflicts, but such mechanisms are not deployed today.

And that is fine. Deployments do not need to be perfect, they have the
blunt tool of filtering the PAD out entirely if they think their tools
are not good enough to do the filtering they'd like. The result is the
same (you have no PAD available) but due to a conscious admin decision,
not due to vague/unspecified "trust" issues.

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

The PAD specification explicitly mention filtering and may require it in
some parts, I surely hope you are "even OK with the same ad-type when
you expect the KDC to apply some filtering" because if you are not it
means you are against the draft.

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

I still don't get this. I think we may be reading some parts of the
draft in completely different ways. This is probably my fault, I must
not have been good enough at conveying information properly, I hope our
discussion can lead to a better text.

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

Then I am talking about federation and I do not see any difference
between federation and a cross-realm trust from this pov.**

> That will require different processing rules
> and thus should have a different ad-type.

No.

> It's even more true when you want services to be suspicious of the attributes.

I always want the KDC that vets the PAD to be suspicious of attributes.
Services my add some paranoia too if they so chose, but should not be
required to (I do not consider mapping ids as being suspicious, maybe
you do ?)

HTH,
Simo.

*note that you need to define "federation" a lot better and explicitly
come up with language that clear point out the difference between your
idea of federation and a cross-realm trust, or we will be just not be
able to convey a coherent message here.

**The paragraph I am replying to seem to give a better glimpse of your
concept of federation, although it doesn't change mine as I do not see
it as a distinction between what you say and what cross-realm trust
implies. I see the same level of distrust can be applied.

Simo.

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

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