Subject: Re: [Ietf-krb-wg] Comments on adopting draft-sorce-krbwg-general-pad as a work item

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 20 Dec 2011 20:45:50 -0500

On Sun, 2011-07-17 at 18:36 -0500, Nico Williams wrote:
> > I still fail to see why you need this information in the ticket. Can you
> > make a compelling example of a problem solved by this session or ticket
> > Id that cannot be solved otherwise ?
> 
> Auditing is one.  Today there's no easy way to link tickets to TGTs.
> That's annoying.  There's also no way to link events on multiple
> services to a single initial TGT.  That's also annoying.

It's extremely annoying.  As an operator, I really want to be able to
link these events, so I can determine which TGS requests and which
resulting tickets used what TGT.

> > I understand what you'd like to use it for, now what you do if the
> > receiving machine is not able to handle the URI type you pass in ?
> 
> That's a local problem, with local answers (e.g., no login, or login
> with / as $HOME, or whatever).  Also, remember, I want multiple URIs
> to be included.  Services should use the first URI that works for
> them.

Note that the answer to the question is about the same as "what if the
attribute says /home/nico and that directory doesn't exist?"

Just to take an answer from a problem a colleague is currently working
through, it'd be useful if it were possible to present a list that
includes, for example...

/home/jhutz
/afs/andrew.cmu.edu/usr21/jhutz
/afs/andrew.cmu.local/usr/jhutz

A machine that takes the first of those that exists will give me a local
home directory if I have one, otherwise my AFS home directory.  And, it
will work on a set of servers behind a firewall where they can't see the
regular andrew.cmu.edu cell but can see the special andrew.cmu.local
cell, which exists mostly to provide home directories for such machines.

Today, what's required is that those values be returned in three
separate LDAP attributes, with each individual machine having local
configuration to determine which attribute is used on that machine.  And
that doesn't account for the case where jhutz has a local home directory
on some machine but nico does not.

> > - What do you do in a trusted realm with a URI you are not allowed to
> > access because you have a one way trust anyways ?

In fact, that's exactly one of the cases I described above.  Note that
my example used only directory names, because I happen to have the
luxury of living in an environment where the concept of a globally
consistent filesystem namespace has been around for a year or twenty.
However, I fully support Nico's proposal to use URIs, which are the
Internet's closest thing to a globally consistent filesystem namespace.

> >> So let's provide two attributes: one specifying a POSIX path for the
> >> homedir, the other providing location URIs for the homedir.

That seems silly.  Maintaining two parallel lists makes it impossible to
represent relative ordering between the entries.  It's also completely
unnecessary, since any filesystem path can be represented by a URI.

I also reject the notion that the plain-path representation is required
for backward-compatibility reasons, particularly if the attribute is
optional anyway (and it is, since the entire PAD is optional!).  There
are no preexisting implementations of this feature, so there is nothing
to be backward compatible with.

> My answers above relating to homedirs apply equally well to shells,
> except for the fact that we don't need URIs for shells :)

They apply even better to shells, since in many environments users get
to say what their favorite shell is, while they generally have no
control over their homedir.

> >> I've known many a user who has their shell set to the lowest common
> >> denominator, plus logic in their ~/.profile to set SHELL to the best
> >> shell on the system and then exec's that shell if it's not the same as
> >> the lowest common denominator.  Is this convenient?  No, it's not --
> >> it's an obnoxious complication.
> >
> > It should just be made easy to configure on local systems IMHO.

If you're going to keep punting attributes to "configure locally", then
you essentially require a lookup to another directory service, in which
case why are we talking at all about attributes that in fact have
nothing whatsoever to do with authorization?

> >> >> - Nowhere is the name of the user's primary group delivered.  I
> >> >> suggest removing PAD-Posix-GID and instead declaring that the first
> >> >> group in PAD-Groups is the user's primary group.
> >> >
> >> > The idea is that you can find the name in the list of groups. This avoid
> >> > the need to provide any special ordering.
> >>
> >> That means the primary group must appear in two places.  I've seen
> >> setups where the user's primary group does not appear in the user's
> >> supplementary group list (e.g., to deal with the ancient AUTH_SYS 16
> >> group limitation).
> >
> > Systems with this limitation can decide to remove the primary gid from
> > the supplementary group list at PAD decoding time.
> 
> I don't understand what you're saying w.r.t. having a name for the
> primary group.  Will we, or won't we have that?  And if we will, how?

I think he's saying that to get a name, you have to include the primary
group in the supplementary group list.  IMHO, that's a mistake, because
it means the protocol discards information.  Discarding information
should be done as late as possible, not as early as possible.

> >> Also, we don't want transited realms to do ID mapping.
> >
> > Why not ?
> >
> > Translating one at the time the cross realm TGT is returned means you do
> > not have to recompute the PAD every time the client asks for a new
> > service ticket. This would make it much more lightweight on the KDC.
> 
> If the transited KDCs don't do ID mapping that's... "much more
> lightweight on the [transited realms'] KDC(s)".

I don't think we want to _require_ transited realms to do ID mapping,
because it's work.  But I also don't think we want to preclude them from
doing so, since that's a very useful function to perform at federation
boundaries.  Thus, we need enough information to know which realm's IDs
are used, since we can assume neither that they belong to the latest hop
nor to the user's home realm.

Of course, a service's KDC almost certainly wants to do translation,
rather than leaving untranslated IDs belonging to some foreign realm.
But that's primarily a policy decision, and not up to us.

> >> >>  - A full ASN.1 module would be nice.
> >> >
> >> > Once we are all in agreement ASN.1 is the encoding to use, there have
> >> > been mild suggestions to use something else, although I am not in favor
> >> > some seemed to have somewhat stronger feelings.
> >>
> >> I recommend that you use the Heimdal ASN.1 compiler to generate the
> >> code if at all possible.
> >
> > This is something that should be discussed with the implementer.
> > I don't think it is something we can/should discuss on the IETF list.
> 
> There's no law against me mentioning a possible implementation choice.
>  It was friendly advice.  You're free to ignore it.  :)

<hat type="chair">
Discussion of and advice on implementing Kerberos and related protocols,
including protocols under development, is certainly on topic for this
mailing list.  I certainly would not expect one of our documents to
recommended the use of a particular ASN.1 compiler, but it's not an
inappropriate comment in a discussion.
</hat>

-- Jeff

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

---

From: Nico Williams <[email-masked]>
Date: Wed, 21 Dec 2011 12:35:49 -0600

> nothing whatsoever to do with authorization?

Exactly.  But also local configuration is really oh so 1985.  Also, if
the point of the PAD is to make it so a site need not put its
LDAP/whatever infrastructure outside their firewall, and to allow them
to have outbound trusts only, then we need to stuff every attribute
into the PAD that the user will need the RPs to have access to, else
the user experience will not be good.  For some federated use cases
home directories will be utterly superfluous, but for others it might
be (and I think will be) critical.

We don't need to mandate a home directory attribute be present, but we
do need to specify it, and you make great points about home directory
a/v representation as a list of URIs.

> But that's primarily a policy decision, and not up to us.

Remember that ID mapping can be a purely local function (as
SID<->UID/GID mapping is in some configurations on Solaris), but for
this we need enough information preserved by the KDCs.  I'm not
against KDCs doing ID mapping, as long as there's an option to either
not do it or to do it in addition to passing through the original ID
data so the RP can do its own ID mapping if the KDC's mappings are not
useful to the RP.

> inappropriate comment in a discussion.

It never crossed my mind to have any of our I-Ds/RFCs recommend a
particular set of implementation tools.  I would be shocked if anyone
did!

I will insist that we use a formal syntax and transfer representation
for the PAD.  We might haggle over what that syntax and transfer
representation will be, but the syntax must be at least as expressive
as XDR and preferably as expressive as the subset of ASN.1 that we
have been using in Kerberos V5 all these years.

Availability of tooling, and ability of the existing community of
implementors to adapt to [any new to them] syntaxes or transfer
representations, is and should be at least somewhat relevant.  Not all
Kerberos implementors will have an easy time with alternatives to
ASN.1/DER, such as XDR or NDR, but all have managed ASN.1/DER,
obviously, and ASN.1/DER is what we have been using for Kerberos for
many years.  ASN.1/DER should generally be considered the advisable,
default choice for KRB-WG work.

My preference is strongly in favor of ASN.1/DER for Kerberos
extensions like the PAD.  I have and would use alternative
syntaxes/encoding rules in certain projects, and I'd really like PER
to be an available choice, but in the context of Kerberos I would
rather be conservative as to this choice.

Finally, given that the PAD is essentially a bag of attribute/value
pairs where the attribute names and value representations will often
be given by external standards (e.g., SAML), the choice of syntax and
encoding rules seems unlikely to be much importance.  Verbosity of
encoding and implementor-friendliness are the most significant
differences to be had between available choices.

Regarding verbosity ASN.1/DER with implicit tagging will generally be
more space-efficient than NDR, ASN.1/DER with explicit tagging will
generally be no more space efficient than NDR, NDR will be slightly
more efficient than XDR (but the same for a bag of attribute/value
pairs), XER will be the most verbose, and finally PER will be the most
space-efficient (but probably not very much more so than ASN.1/DER
with implicit tagging).

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Dec 2011 22:12:00 -0500

On Mon, 2011-07-18 at 13:06 -0400, Simo Sorce wrote:
> On Mon, 2011-07-18 at 16:46 +0000, Luke Howard wrote:
> > > Yes I understand what's the concern here, on the other hand using
> > > something like FOO\name as the username instead of [email-masked]
> > > is much more compact for users.
> > 
> > I disagree, this seems like a Windows-ism that you're trying to
> > propagate. The rest of the world is used to RFC822-ish names.
> 
> I just want to allow people to use that form, not dictate it.
> And the only way to allow that form is to carry around the short name.

In fact, you're conflating two issues:

1) Use of short "domain" names instead of fully-qualified DNS names.
2) Use of NT4 domain syntax instead of Kerberos or RFC822 syntax.

Note that there's nothing stopping you from using NT4 syntax with a
DNS-based domain name, and modern Windows even permits this.  So no,
carrying short names is _not_ required to support this syntax; it's
required to allow people to type or see a short name instead of a
fully-qualified one.  Which is fine as long as you don't make
authorization decisions on the basis of a short name taken out of its
proper context.