Subject: [Ietf-krb-wg] PAC/PAD/AuthZ Data Interoperability

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 21 Dec 2010 17:55:30 -0800

One of the things that struck me from Friday's telecon (sorry I couldn't be there in real time) was that we *already* have three different flavors of authorization data in the wild, and we *already* need to worry about how they interact.  This seems bad.

Seems to me that addressing the interoperability of systems in the presence of these data is at least as important as the specific PAD under discussion.

Suppose a service, through some TBS cross-realm scenario, gets a ticket with a Microsoft PAC, an Apple PAC, and a RedHat/standard PAD.  How likely is it that the UID number (for example) is the same in all three?  Which one of the three should it believe?  Will that user always arrive with the same, exact collection of AuthZ data types (and if not, then how do we guarantee the user still gets the same resolution)?  Does solving this problem require deployment/configuration options?

I'll grant that these problems are related to the transitive cross-realm issues Nico discussed.

I'll also grant that these problems are not new, just aggravated.  I think that argues that we need to try real hard to re-use the existing cross-realm solutions so we don't create new problems.

Yeah, I know, motherhood-and-apple-pie and all that.  I'm just not thinking of solutions I like is all.  I don't have ready access to example data to investigate either.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Dec 2010 20:52:36 -0600

On Tue, Dec 21, 2010 at 05:55:30PM -0800, Henry B. Hotz wrote:
> One of the things that struck me from Friday's telecon (sorry I
> couldn't be there in real time) was that we *already* have three
> different flavors of authorization data in the wild, and we *already*
> need to worry about how they interact.  This seems bad.

Well, no, we don't.  We have many of what we call "authorization-data
types" in Kerberos.  But very few (none standardized) that bear much
useful information about the client principal.  Simo's proposal would be
the first standard such a-d type (assuming it reaches Proposed
Standard).

> Seems to me that addressing the interoperability of systems in the
> presence of these data is at least as important as the specific PAD
> under discussion.

Indeed.  Solaris shows that it's possible to get by with the AD PAC.
Perhaps we don't need to define a new one.  OTOH, there may be
improvements to be made over the MSFT AD PAC that warrant a new design.

> Suppose a service, through some TBS cross-realm scenario, gets a
> ticket with a Microsoft PAC, an Apple PAC, and a RedHat/standard PAD.

A good question might be: can we get by with standardizing one of the
existing PACs?  How extensible are they, and what extensions might we
need in order to make them acceptable as a standard?

> How likely is it that the UID number (for example) is the same in all
> three?  Which one of the three should it believe?  Will that user
> always arrive with the same, exact collection of AuthZ data types (and
> if not, then how do we guarantee the user still gets the same
> resolution)?  Does solving this problem require
> deployment/configuration options?

Sam, Simo and I agreed on the call that the service should be able to
map the original data from the PAD, even when "mapped" data are missing.
I believe that's feasible whether there's three different types of PACs
in the same Ticket, or just one.

> I'll also grant that these problems are not new, just aggravated.  I
> think that argues that we need to try real hard to re-use the existing
> cross-realm solutions so we don't create new problems.
> 
> Yeah, I know, motherhood-and-apple-pie and all that.  I'm just not
> thinking of solutions I like is all.  I don't have ready access to
> example data to investigate either.

I don't think we can forbid new PACs, nor would I want to.  The
interoperability problem is for the implementor of the service to deal
with.  I'll note that having more inputs to whatever mapping functions
may be needed on the service end, is not remotely a hindrance, but quite
useful indeed!

Also, let's be clear what we mean when we speak of "UIDs".  We mean
"POSIX User IDentifiers", which POSIX defines to be _local_.  Of course,
they're not quite that local: NFSv_3_ (but not NFSv4) and various
backup/archive formats use UIDs on the wire/tape/disk without any
identification of which namespace they might be valid in.  However, I
would argue that NFSv3 is not and should not be a concern of this WG's;
ditto backup/archive formats.

Of course, being able to reliably and robustly obtain UIDs from a
namespace shared across some administrative domain spanning more than
one end system is still quite useful.  I believe that there is room for
a standard solution in this space, just not one that Kerberos
implementors should be required to implement in KDCs.  Note too that I
believe that any solution requiring distributed, ACID mapped UID
allocation semantics is not likely to be what one might call robust or
reliable, not without a significant amount of redundant, distributed
infrastructure.

Nico
--