Subject: [Ietf-krb-wg] Open issues on draft-ietf-krb-wg-general-pac

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Feb 2012 12:45:32 -0500 (EST)

Hi.  Doing a chair review of the discussion here are issued opened
prior to the document split that have as far as I can tell not been
closed.

Would it be valuable to start using an issue tracker at this point?

1) behavior of KDC and service

Leif raised the issue that semantics are not sufficiently well specified.

2) Semantics around domain uuids

This is a specific area where the semantics are insufficient.
I think this has been renamed to DUUID.

* renaming of domains

Are there any semantics KDCS and services must follow?
I.E. MUST a KDC keep the DUUID constant if it refers to the same domain and no rename has happened? (presumably yes)
MUST/SHOULD/MAY the KDC keep the DUUID constant when a realm is renamed  if it corresponds to the same realm?

What semantics need a service implement?
MUST/SHOULD a service map based on DUUID rather than realm name?

* What controls domains asserting the right uuid?

Nico and I think Greg raised issues about filtering DUUIDs and validating them.

4) Why is it domain not realm?

Some of this has been fixed in the recent draft, but we should have a better understanding of where we 

5) Where is the trust model specified

We need a clear discussion of the trust model for both documents.

6)  Home directories and URIs

Will require discussion on the list.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Wed, 15 Feb 2012 14:24:53 -0500

> Would it be valuable to start using an issue tracker at this point?

If you think it is appropriate.

> Leif raised the issue that semantics are not sufficiently well specified.

In what areas ? Trying to get a list of items to address here.

> I think this has been renamed to DUUID.

it was Domain UUID but has been renamed to UDID (Unique Domain ID)

> Are there any semantics KDCS and services must follow?

I would say the actual renaming of realms is not in scope.
What the UDID allows is to handle file permissions for those systems
that us a 'Domain ID' to store Access Control Lists. Admittedly only
Windows and Solaris with ZFS do that now. On other Posix sytsems Samba
emulates that by storing ACLs in extended attributes.
So this is also an interop attribute used by those system that have a
concept of domain namespaces for user/group identifiers.

> I.E. MUST a KDC keep the DUUID constant if it refers to the same domain and no rename has happened? (presumably yes)

Yes, it MUST.

> MUST/SHOULD/MAY the KDC keep the DUUID constant when a realm is renamed  if it corresponds to the same realm?

I would say MAY, as it should be an admins decision. Of course they'll
live with the consequences whatever their choice.

> What semantics need a service implement?

A service is not required to care about this attribute if it doesn't
want to.

> MUST/SHOULD a service map based on DUUID rather than realm name?

No, services are not required to take UDID in account, but they should
be consistent. Either always or never care about it.

> Nico and I think Greg raised issues about filtering DUUIDs and validating them.

I think this problem is quite similar to the short-name problem, and
should probably use the same rules for validation.

> Some of this has been fixed in the recent draft, but we should have a better understanding of where we 

I am not sure I have a good reason. I think at some point I was
considering the fact a REALM may be associated to a domain name that is
completely different from the realm name. But it probably doesn't really
matter within the PAD.
I think the only case where it may matter is if the target machine wants
to derive an email address from the data at hand and uses
<IPA-username>@<IPA-DNS-Domain> to stitch it together. Not sure this is
something we should encourage though. It is probably better to have an
email address conveyed in AlternateNames, so unless someone else reminds
me of a good reason to have it in, I guess we could just drop this
attribute.

> We need a clear discussion of the trust model for both documents.

ack.

> Will require discussion on the list.

ack.

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

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Feb 2012 13:47:05 -0600

> concept of domain namespaces for user/group identifiers.

I'd like to clarify that it's ZFS much more than Solaris that stores
SIDs on disk.
ZFS has been ported to numerous other operating systems (MacOS X, FreeBSD,
Linux, and probably others), and while it probably doesn't store SIDs
on any of those
at this time, it may only be a matter of time until it does.  Also, there are
OpenSolaris-derivatives that do store SIDs on disk in ZFS, but they
are not Solaris
proper.

Back to the domain/realm rename issue, my position is as follows:

   I'd like domain/realm rename to be feasible, but in a pinch I'll settle for
   declaring that to be infeasible, but the I-D (and ultimately the RFC) must
   be explicit on this point.  But first we should make an effort to make
   this feasible.

It would help now to discuss what's necessary in order to support
domain/realm renames.  I believe there's two ways to do this:

Domain/realm rename method 1: assign unique IDs to domains/realms
and preferably also provide a name resolution mechanism.

Domain/realm rename method 2: pass around {current-name,
[original-name], date-created} in the PAD.  This is sufficient to
allow filesystems to store {original-name, date-created} and does
not require a name resolution mechanism.

I prefer method 2 because it seems simpler, though it does require
that KDC keep a history of domain/realm renames (something that I
think is fair to assume, at least within a "forest").  We may need to
have a notion of domains/realms being members of zero, one, or more
forests, and we may want such forest names to appear in the PAD.

Nico

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Feb 2012 15:18:16 -0600

> Some of this has been fixed in the recent draft, but we should have a better understanding of where we

Because it's getting to be time to accept that realms are named after
domains?  :)  But, sure, the right thing is to say "realm".

> Will require discussion on the list.

We had one today on the concall.

Simo seemed to think that the URIs would be for all the possible
locations of a user's home directory on potentially thousands of
servers.  But that's not the case, at least I can't think of any case
where one would want that, and IIUC neither could Jeff H.

My point is that a POSIX path can be a URI (/net/server/path) or not,
but if not and there's no local homedir then we'll need... a federated
automount map?  No, that's too much complexity.  What Jeff and I are
asking for would be optional: a sequence of zero, one, or more URIs,
but probably never more than one per relevant URI scheme.  Even if
Simo himself has no use for this Jeff and I believe we do.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 15 Feb 2012 16:54:10 -0500

> Simo himself has no use for this Jeff and I believe we do.

So, as I mentioned on the call, I believe the question of whether we
have a single item or a list is separable from the question of whether
the item(s) can be URIs or if only paths are permitted.

I don't actually think "path plus list of URIs" fits the bill.  This
field should tell the target service where to find the user's homedir
(which could be one place or a list of places to search); in the event
that it's on some server, we have business telling the target service
where the fileserver/whatever is, but not where to mount/copy/install it
on the local machine.  This is somewhat confused by the fact that the
most common cases for "where to find it" are going to be paths visible
on that machine (either locally or via some distributed namespace), and
the most common thing to do with those is just use them as the homedir.

So, what I'd like to see is _one_ list, which can contain zero, one, or
more than one items.

The list is first filtered according to local policy and the particular
situation.  For example, you eliminate items that correspond to
resources that don't exist or which you don't know how to access or are
unable to access, and you may also eliminate items due to policy that
restricts what homedirs are acceptable.  The filtered list is then
ordered according to some priority rule, which may be some combination
of local policy and the order provided by the KDC(*).  After that, the
first (best) item is the one that is used.

The question of _how_ it gets used is up to the implementation and
policy.  For example, it might end up being the homedir returned by an
NSS module, or it might get used in an /etc/passwd entry that gets
created for that user.  Or it might become where /home/<user> points to,
or get copied or mounted or symlinked into some local location which
then gets used as the user's homedir.

If there are zero entries left after filtering (possibly because there
were none to start with), then the behavior is up to local policy.  That
could mean a (computed or static) default value, or getting the
information from some other source, or not letting the user do things
that require having a home directory.

Of course, all of these policy knobs are up to the implementation.  It
would be reasonable for an implementation to take the first entry, or
the first entry that is a path, and just use that.  

Separate from this is the question of whether to permit URIs or just
paths.  This is not a question of representation so much as one of
whether we can only name directories that can be accessed via the
filesystem(+) or if we can also name other kinds of remote things.  For
Windows interop, you might want the user's homedir to be on some CIFS
server, and named by a UNC path.  But that's not-a-local-path, and no
different from a URL as Nico proposes (except by being less flexible).

Note that I am mostly neutral on the question of whether to permit URIs.
That's because I don't need them -- I've lived for over 20 years in an
environment with a global distributed filesystem namespace that looks
the same on _every_ machine(%), so I _can_ represent homedirs as paths
that will be the same on every machine that can access them.

-- Jeff

(*) To be clear, the provided list is ordered, according to how the KDC
has been configured and/or where it got the data.  However, the target
service may have configuration which partially or completely overrides
the order, for example by preferring a local directory over a remote one
even if it occurs later in the list.

(+) That is, can I just chdir there?  If something has to be done to
mount the thing, then this test fails.  Note that automounters let you
have remote paths that are accessible this way, as does use of things
that are pre-mounted.  But those require that the KDC knows something
about the automount map or the things that are pre-mounted.  That's
probably doable in some deployments, but utterly impossible in others.

(%) Actually, when I got here, we had two of those.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Feb 2012 21:14:17 -0500

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

I'd like to see comments from the participants on:

1) Should we support telling servers where to mount central homedirs
from?

2) If so, do we want to provide a hint about where to locally mount the
homedir?

3) Is relying on distributed automouters/namespaces sufficient for the
level of central homedir support we need?

Other comments are fine too, I just want to tease these apart because I
think I see disagreement on these issues.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Feb 2012 21:50:59 -0600

> 1) Should we support telling servers where to mount central homedirs

Yes.

> 2) If so, do we want to provide a hint about where to locally mount the

The POSIX file path for the home directory is possibly a URI of its
own, if, for example, AFS is in use, or if NFSv4 with the new global
namespace features, or if one uses the /net/ special automount point.
So it's not just "where to mount this thing".

That said, it's certainly convenient to have a reliable path so that
it can get backed into scripts (I know, use $HOME).  And if we could
rely on a global namespace, then I'd just drop the URI thing.  But I
don't think we can, not in federated realms that aren't remotely in
the same "administrative domain", which I thought was part of what the
PAD was all about.

Thus my answer is a qualified "yes".

> level of central homedir support we need?

Automounters?  No.  Global namespaces?  Yes, or, rather, I wish
global, federated namespaces were sufficiently universally deployed,
but it may be a few years more before that's so, and if I were
sufficiently optimistic then I could just drop the URI thing.
Evidently I'm not sufficiently optimistic :/

Thus my answer to this question is something like "yesnosomedaymaybe".

Nico

---

From: Simo Sorce <[email-masked]>
Date: Thu, 16 Feb 2012 00:28:39 -0500

> the most common thing to do with those is just use them as the homedir.

Although I agree a local machine can always override whatever path we
pass in as a hint, I think we absolutely need to pass in the actual path
if available.

At least in the Linux world, way too many applications store absolute
file names in their configurations, data, etc... if you do not use the
"canonical" path to mount the home directory you are up for surprises.

> first (best) item is the one that is used.

Works for me.

> then gets used as the user's homedir.

Agreed, local policy will always prevail here.

> that require having a home directory.

Concur.

> the first entry that is a path, and just use that.  

Agree.

> different from a URL as Nico proposes (except by being less flexible).

Windows UNC paths can be translated into smb URIs if we want to mandate
URIs.

> that will be the same on every machine that can access them.

I think that if we really want to represent remote resource than a (set
of) URIs is probably the way to go. It would be really sad to see
implementations stuff in arbitrary data that you have to know (somehow)
how to interpret.

A local path can be easily represented by file:///home/user which is
easy to construct from existing directories data by simply slapping
file:// in front of the currently stored path (if any).

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Thu, 16 Feb 2012 00:32:19 -0500

> where one would want that, and IIUC neither could Jeff H.

No, I think this could be used badly, and have environments that have
10s or 100s of URIs.
But, after some consideration I think that the admins should be free to
shoot themselves in the foot in this case, they can as easily remove
URIs as they add them.

> Simo himself has no use for this Jeff and I believe we do.

I think I can accept this request, and leave to the implementation the
freedom to implement storing multiple URIs or paths in the PAD or not.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Thu, 16 Feb 2012 00:36:59 -0500

> 1) Should we support telling servers where to mount central homedirs

Nico and Jeff seem to really want this feature badly.
I think I can live with that.

> 2) If so, do we want to provide a hint about where to locally mount the

Yes, KDCs SHOULD include the local homedir path if available to them.
Hosts MAY ignore it.

> level of central homedir support we need?

I think for Nico and Jeff it is sufficient. If not admins can always
devise local methods to deal with users home directories, just like it
is done today with LDAP servers and RFC2307(bis) which does not provide
URIs.

Simo.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Feb 2012 08:36:37 -0500

>>>>> "Nico" == Nico Williams <[email-masked]> 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.

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.

--Sam

---

From: Simo Sorce <[email-masked]>
Date: Thu, 16 Feb 2012 09:17:48 -0500

> assumptions that bind it within one organization.

Do you have a write-up of what these assumptions are ?

> influences some of these discussions somewhat.

I am not sure the PAD itself is anything for/against federated
cross-organizational contexts. It is a matter of how much code/policy
decisions you want to put in your KDC filters. I think you could use the
PAD in a federated scenario, but int that case you may end up generating
on the KDC (or a dedicated service the KDC has access to) most of the
contents of the PAD when the cross realm TGS is used and a ticket is
requested.

Simo.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Feb 2012 10:09:41 -0500

>>>>> "Simo" == Simo Sorce <[email-masked]> writes:

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

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

---

From: Simo Sorce <[email-masked]>
Date: Thu, 16 Feb 2012 11:09:40 -0500

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

> are. That is people grant access to all authenticated users to some

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.

> verify in some hierarchical manner.

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

> easier and stuff like that.

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

> Why? In part because I'd expect applications to make different

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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 16 Feb 2012 11:29:09 -0500

> assumptions that bind it within one organization.

It always confuses me when people say "Kerberos is not federated".
Of course it is.

I have cross-realm relationships with a variety of organizations,
ranging from other parts of CMU to other universities to outside groups
with whom our only relationship is that we've agreed to enable
authentication to services in one organization by users in another.  I
use Kerberos-authenticated services in other realms nearly every day.
How is this not federated authentication?

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Feb 2012 11:32:19 -0500

>> >> 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.
    >> 
    >> 
    >> 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.
    >> 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-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Feb 2012 12:04:28 -0600

The biggest problem with what you say Sam is that if it were correct
then it would be an indictment against all existing multi-mechanism
capable GSS-API applications, not just indictment of Kerberos.

There is some truth to what you say, and as you say it's more about
the attitude of people using Kerberos in specific cases than it is
about the protocols involved.  But in cases where people are using
Kerberos with such an attitude and via GSS the problem affects your
EAP mechanism too (bear with me please).

In particular I would say that we're missing a few things to make
Kerberos meet your vague notion of federation:

 - better policy expression mechanisms for applications
    - including actually useful name attributes so that generic
      policy might be implemented for GSS apps

   But you're going to have the latter problem with any
   GSS mech until we specify some name attributes.
   And adding better policy to some mechs but not
   others serves only to make GSS apps more mech-
   specific.

 - better policy expression mechanisms for TGSes for
   cross-realm transits

 - authz-data containers that allow us to make per-hop
   statements about who issued what, and possibly using
   digital signatures to authenticate each hop's statements

   I'm not sure how much this is necessary.  If trust chains
   are short enough (zero transited realms, say), then it
   isn't necessary at all.

 - trust routing -- capaths suck, and so do hierarchical trusts

   I think this is probably the single most important missing
   piece in Kerberos for web scale deployment.

   There's also no easy way to bootstrap short trust paths
   from longer ones.

Also, I would very much like to hear your thoughts as to whether
Windows' Kerberos implementation is an exponent of the attitude you
describe.  Active Directory has quite a few controls on trust, and PAC
filtering and so on (certainly more than MIT krb5).

Nico

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Feb 2012 13:57:50 -0500

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> The biggest problem with what you say Sam is that if it were
    Nico> correct then it would be an indictment against all existing
    Nico> multi-mechanism capable GSS-API applications, not just
    Nico> indictment of Kerberos.

I'm not going to address the  questions of what would it take to make
Kerberos federation-friendly.

It's a hard problem and it's not one I'm interested in solving at this
time: I have too much else going on.
(Well, trust routing for capaths is something I'm somewhat interested in
actually, but don't have a lot of time for.)

I'd like to start with responding to your tone.
Saying something is an indictment implies there's something wrong.
I don't think that's true at all.

I think the GSS-API is fine in this regard and to the extent I had
concerns about GSS-API I've already proposed solutions that kitten has
adopted.

I think Kerberos is fine. Kerberos doesn't have some
capabilities. That's OK: Kerberos never promised to be the only security
mechanism anyone would ever need.  Kerberos is great in many deployments
and is the widely successful enterprise security mechanism.

If you want to add capabilities to Kerberos that's fine; my plate's full
right now, but I'd be delighted if people want to enhance Kerberos.

There's nothing wrong with the PAD.  I actually think the PAD is easier
to specify and implement if it doesn't take on the full federated
context.

I don't think there's anything wrong with multi-mechanism GSS-API
applications.  We need to be careful in how we specify attributes to
make it possible to write these applications.  You shouldn't use the
same name for an attribute that should simply be trusted by an app as
for an attribute that contains similar data but requires the app to vet
it.  It's fine to map a requires vetting attribute into a just-trust-me
attribute if you've somehow done the vetting in a policy or
local-context specific manner.

Could we have done better with naming extensions?  Of course. Will we
find improvements we'd like to make in the future?  Probably.  However
what we have allows us to make significant forward progress so I'm
happy.

--Sam

---

From: Simo Sorce <[email-masked]>
Date: Thu, 16 Feb 2012 13:05:36 -0500

> having one realm "trust" another is just not how you think in a

Please enlighten me.

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

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

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

> trust assumptions are involved and to make your identifier choice etc

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

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

> to do all the vetting at the point of import.

And this is "against" federation how ?

> 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 :-)

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

> way to set up reasonable filters for inter-federation.

I do not understand this statement at all.

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

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

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

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

> 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

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.

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Feb 2012 16:24:43 -0600

On Thu, Feb 16, 2012 at 12:57 PM, Sam Hartman <[email-masked]> wrote:
> [...]

We've talked about this off-list and I know now that you did not mean
that you took my use of the word "indictment" as a personal slight,
and neither should I take the comment about tone personally either.

For the record, my use of "indictment" was not literal, nor, I think,
out of the ordinary for current English language usage; my use of it
was intended to probe the edges of what you were saying.

Sam and I then talked about what we might want in terms of policy and
GSS APIs.  I'm going to cut to the chase rather than respond line by
line to Sam's message for the sake of brevity as this reply is already
getting too long.

To summarize what's non-federation-like about Kerberos, besides the
items I identified earlier there's also just the fact that without
SAML or something like it with digital signatures we always depend on
the transit realms and the service's realm to vouch for things.  But
this is really just a result of not having digitally signed
authorization-data containers, and there's no reason that we could use
SAML to provide this.

My conclusion is that Kerberos doesn't really have a problem with
federation that couldn't be solved in the same ways that GSS-EAP is
doing.

We also discussed concerns I have with how Sam's GSS-EAP project is
handling policy, namely the fact that there's an implied local policy
that the application does not get to choose or specify, and we
discussed problems that Sam has with our current name attribute model
in the context of Kerberos.

We discussed several different but related things (Sam, please check
that I left nothing out):

 - We already agreed on a need for an "issuer" attribute of names
   and name attributes.  Sam points out that in the absence of
   digital signatures by issuers we end up needing what we
   identified as a concept of "voucher" -- realms that vouch for
   others issuance of various name attributes.

   For example, in Kerberos with the MSFT PAC or the PAD we
   have the service's realm's KDCs vouching for all of the attributes
   in the PAC/PAD, even though those attributes might have
   different issuers (e.g., the client's realm and any transited
   realms).

   The way we would do this is by specifying name attribute names
   that can be used as prefixes for other name attributes.

   To find the issuer of a principal name you'd apply
   GSS_Get_attribute_name() to the NAME and the issuer name
   attribute.  To find the issuer of a name attribute you'd format a
   string as <issuer name attribute name><space><attribute name>
   and get that.

   To find the "voucher" for a NAME or name attribute it'd be the
   same thing, but with the voucher name attribute name.

   Let us call these meta-attributes.  The API is the same as we
   already have in the current I-D (and it already includes the idea
   of composable names).

 - In Sam's GSS-EAP project local policy is applied by the mech
   on the acceptor side, and the application has no choice as to
   policies.

   We both agree that this is not really a good state of affairs.

   Rather than delve into the PGSS idea as a way to specify
   application-specific options I proposed a pair of functions that
   have very simple prototype and semantics and which can very
   quickly be provided even if initially they'd be trivial stubs:

    - GSS_Filter_name()

      This function takes a NAME and a policy name and outputs
      a new NAME (or modifies the input name if no output is
      requested, just like GSS_Add_cred()).  The new/modified
      name may lose some attributes, gain some others, and
      some attributes may have different meta-attributes.

      Inputs:
       - name INTERNAL NAME
       - witness INTERNAL NAME OPTIONAL
       - policy BUFFER OPTIONAL -- system default if not provided
      Outputs:
       - major and minor status, of course
       - output_name INTERNAL NAME OPTIONAL

      The witness argument is for applications like AFS' rxgk,
      where the witness argument would be a NAME of the client
      *host* instead of client *user*.  The witness can be used for
      computing privileges to be granted to the user given the
      client's assertion of local privileges in effect and the server's
      willingness to grant any/some/all of those to certain users
      on certain clients.  E.g., the server can intersect maximums
      for the client and user with the set of privileges asserted in
      the user NAME object.

    - GSS_Authorize_session() (or similar name)

      This function would take just a name and a policy name
      and it would return a boolean indicating whether the
      given principal is allowed access to the application.

      Variants that deal with authorization to operations on
      objects would not be portable, so we'd not specify them.
      Perhaps we could have a GSS_Impersonate_name() that
      sets the current process' execution context to be like what
      the named user's would be -- portable apps could spawn
      a child process to run as the user and perform operations
      on [e.g., filesystem] objects on behalf of the parent process.

 - We talked about how the PAC's netlogon structure and the
   PAD are both attributes and contain attributes.

   For example, each SID in a PAC is effectively an attribute
   on its own.  For domain SIDs the issuer is the corresponding
   domain.  For well-known SIDs the issuer depends on the
   semantics of the given SID.  Either way the voucher is the
   service's realm.

 - We talked about attributes like "full name" that may have an
   issuer/voucher yet not necessarily be produced by either.
   Consider systems where the user is allowed to set their
   full name...  then what is the value of a full name asserted
   by a trusted issuer?  For some attributes we're just bound to
   get sloppy because sloppiness was there all along, and a
   full_name attribute will likely be one of those.

Nico