Subject: [Ietf-krb-wg] Reiview of draft-ietf-krb-wg-generalized-pac-00

From: Leif Johansson <[email-masked]>
Date: Thu, 15 Sep 2011 14:04:59 +0200

At the last IETF I promised to review the PAC draft, here it is...

My overall impression is that the document structure needs to
improve and that a lot of assumptions need to be called out.

The document is trying to define an authorization data structure
that is less complex that something like SAML while remaining
useful for the majority of the usecases. I'm not sure this will
succeed. There is already (imho) signs of feature-creep that may
obviate any gains-in-simplicity over SAML.

Finally I don't really understand the multiple-buffers thing. There
seems to be some extensibility there but it doesn't seem to be
clearly defined, nor is it clear to me what the benefit of the
added complexity is.

Now for some specifics...

* Spelling: s/eterogenous/heterogeneous/ in section 3.

* Suggest add the following text at the end of the last-but-one
paragraph of section 3 to make the argument for the "push model"
sound a bit less theoretical:

"Real-world deployment experience show these problems to be
insurmountable except where there is a very high-degree of
homogeneity (eg single vendor)."

* I suggest switching the order of section 4 and section 5, that
way to read about the overall structure first and then get to
individual attribute definitions. Right now you go from intro and
motivation to some attribute-definitions. Also maybe change the name
of 5 to "Format and Encoding".

* I'm missing language that describes the behavior of the KDC and
the service when processing the PAD. There are some traces of this in
(current) section 6.1 that talks about signing and verification
but I would like to see normative language for the implied message
exchanges even if it turns out to be mostly references to 4120.

* There seems to be a gap in the ASN.1 between the PAD-DATA structure
and the attributes. PAD-DATA refers to AuthorizationData from 4120.
If the intent is that the PAD-* attributes be given ad-type numbers
and their values encoded as OCTET STRING in ad-data then this needs to
be stated explicitly.

If this is the case it seems somewhat wasteful to allocate pa-type
number (yes I know we have 32 bits) for every conceivable future
attribute type and it will also make it more difficult to do local
experiments/deployments. I would argue for ASN.1 that uses OCTET
STRING attribute types even though it consumes more bits.

*  Comments on the attribute definitions:

- - I don't understand the value of PAD-Short-Domain. I understand
how it might rear its ugly head but I don't see why we should
perpetuate a bad idea. Surely local convention could provide a
mapping from PAD-DNS-Domain?

- - I don't understand PAD-Domain-UUID: isn't a domain name unique
enough? This of course has implications for several of the other
attributes.

* 4.15 - PAD Mapped Attributes

Suggest change 'universally' to 'globally'.

Thats it for now. Hope it helps!

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

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Sep 2011 09:20:30 -0500

> obviate any gains-in-simplicity over SAML.

I would like to see a debate around this.  It may turn out that I
don't really mind if we end up with both, PAD and SAML extensions, but
I wouldn't want to not have the option of using SAML.

> mapping from PAD-DNS-Domain?

IMO it should be removed.  It's toxic.

> enough? This of course has implications for several of the other

Domain names can change (I've seen it happen, sort of).  A UUID would
allow nodes to detect a domain name change.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Thu, 15 Sep 2011 16:57:08 +0200

> allow nodes to detect a domain name change.

But only if there is a mapping somewhere and then that database
is now the new DNS somehow? I still don't get it.

I guess I'm looking for some idea on how domain UUIDs would
work in practice.

	Cheers Leif

---

From: Simo Sorce <[email-masked]>
Date: Thu, 15 Sep 2011 11:16:36 -0400

On Thu, 2011-09-15 at 16:57 +0200, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 

Look at how SIDs works in Windows and in the Solaris CIFS server that
uses SIDs.

Simo.

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

---

From: Leif Johansson <[email-masked]>
Date: Thu, 15 Sep 2011 17:50:39 +0200

> Look at how SIDs works in Windows and in the Solaris CIFS server that

OK let me ask you this then: why aren't REALMs UUIDs then? Presumably
name change will happen _exactly_ as often for REALMs as for domains?

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Thu, 15 Sep 2011 17:52:57 +0200

On 09/15/2011 05:49 PM, Nico Williams wrote:
> On Thu, Sep 15, 2011 at 9:57 AM, Leif Johansson <[email-masked]> wrote:
> Let's say you're a service that has seen a PAD with this domain UUID
> before, and later you see it again, but this time with a different
> domain name.  If you'd recorded anything in a DB that's relevant to ID
> mapping (to mapping IDs from the remote domain to local IDs), then you
> can ensure that the IDs from that remote domain continue to map to the
> same local IDs as before.

Yeah I get that part. I just don't get why this hasn't been a problem
for REALMs (or maybe it is and we haven't solved it?)

	Cheers Leif

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Sep 2011 10:58:47 -0500

> for REALMs (or maybe it is and we haven't solved it?)

They should probably have it, yes.  This brings up an interesting
issue though: we cannot let domains/realms assert any UUID they like
-- this is related to PAC/PAD filtering, of course, so this isn't new.

Nico

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Sep 2011 10:49:16 -0500

Nico

---

From: Simo Sorce <[email-masked]>
Date: Thu, 15 Sep 2011 17:40:35 -0400

> for REALMs (or maybe it is and we haven't solved it?)

You mean in case a REALM is renamed ?
I guess it has been historically so hard to rename a REALM that that's
not been considered viable/desirable/possible.

The only problem I may see with realms is if you remap user names when
your machines can be logged into from multiple realms through trust
relationships.

If your machine's REALM is EXAMPLE.COM then you probably map
[email-masked] to the local user 'john', now if user
[email-masked] comes in you cannot map it to 'john', you will have
some rule to map it to something like FOO-john john@FOO or any other
number of schemes. (This is where the short domain name comes handy for
example).

The point though is that if you 'rename' the FOO.EXAMPLE.COM realm (for
example to BAR.EXAMPLE.COM), then you will also need to change the
mappings if you care about maintaining the old user names for some
reason.

The UUID could be used to track this too if you want. It is not tied to
the DNS domain name of the domain. If you think it makes more sense to
call the attribute IPA-Realm-UUID that is fine too.

What the UUID helps to do is to uniquely identify a user, so it is tied
to the identities of the users more than domain or realm names.

Simo.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 15 Sep 2011 23:50:38 +0200

> to the identities of the users more than domain or realm names.

I wasn't arguing for adding REALM-UUIDs but rather asking why its
a problem for domains and not for REALMS. Your answer seems to be
that it _is_ a problem for REALMS. I'm still not sure the problem
(of changing REALM or domain names) is worth the added complexity.

	cheers Leif

---

From: Simo Sorce <[email-masked]>
Date: Thu, 15 Sep 2011 17:59:22 -0400

> (of changing REALM or domain names) is worth the added complexity.

What is the added complexity you perceive ?

It seem pretty straightforward to me, but may be I am making assumptions
I shouldn't ?

Also I did not propose to *add* a REALM UUID, just to rename the current
attribute name, I see no reason to have 2 UUIDs that fundamentally
represent the same thing.

Simo.

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Sep 2011 20:23:54 -0500

> (of changing REALM or domain names) is worth the added complexity.

Name changes are always bad in environments where people use
name-based authorization.

In the Windows/AD space people use SIDs for authorization.  In the
non-Windows/AD space people tend to use some form of name-based
authorization or a name-based mapping to non-name-based authorization
data.

Therefore it's too late to add an alternative, stable domain ID form,
yet it's probably worth doing because perhaps people will migrate to
non-name-based authz methods, or perhaps they'll augment name-based
methods with additional data that make it possible to survive name
changes more easily.  (I'm not so sure about the latter.  Consider
aname2lname rules (or "gsscred" rules): will we really augment them to
properly handle domain renames?  Probably not.  What about Solaris
name-based ID mapping rules (which are one of several options)?
That'd be easier.)

I am concerned about any one realm's KDCs' (or services') ability to
validate the UUIDs (or SIDs) of transited realms' SIDs.  Before we
accept UUIDs (or SIDs) as a method of detecting and coping with
domain/realm name changes, I'd like to make sure that we can prevent
spoofing of these alternate domain/realm IDs by other realms' KDCs.

Nico

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Sep 2011 20:28:01 -0500

> represent the same thing.

The [very good] implication is that realm and [DNS] domain names must
be closely associated.  Environments where a DNS domainname and its
associated Kerberos realm name are completely different tend to
engender all sorts of problems.  Microsoft was quite right to enforce
an algorithmic mapping of DNS domainname to Kerberos realm naming and
LDAP base DN naming.  (I'm not trying to be dismissive of legacy
deployments -- vendors will likely continue to cater to them somewhat,
I'm sure, at least for a while.)

Nico

---

From: Simo Sorce <[email-masked]>
Date: Thu, 15 Sep 2011 23:31:21 -0400

> spoofing of these alternate domain/realm IDs by other realms' KDCs.

So you are not trusting a 'trusted' realm ? :-)

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Thu, 15 Sep 2011 23:35:46 -0400

> I'm sure, at least for a while.)

You are free to do that (we do strongly push FreeIPA admins to have
realm = domain and the LDAP base is always the realm name split into
RDNs), but having a UUId does not force it at all.

All a UUID does int his case, at most, is creating a triplet of DNS,
REALM, UUID. But as I said the UUID is more connected to the identity
information than to names. In terms of relationships it is a property of
the accounts database from which you derive the PAD data.

In those cases where all information is unified into LDAP it can be
thought of representing the specific LDAP directory to which the
Kerberos REALM is bound.

Simo.

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Sep 2011 22:55:04 -0500

> So you are not trusting a 'trusted' realm ? :-)

That's exactly right.  We have transited policy checking precisely
because not all realms are equally trusted by others.

Nico

---

From: Leif Johansson <[email-masked]>
Date: Fri, 16 Sep 2011 08:52:40 +0200

> I'm sure, at least for a while.)

OK I give you that and nowadays it is common to associate UUIDs with
LDAP entries for more or less the same reason. Maybe I'm starting to
see the point.

	Cheers Leif