Re: Open issues on draft-ietf-krb-wg-general-pac

On Wed, 2012-02-15 at 12:45 -0500, Sam Hartman wrote:
> 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?

If you think it is appropriate.


> 1) behavior of KDC and service
> 
> Leif raised the issue that semantics are not sufficiently well specified.

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

> 2) Semantics around domain uuids
> 
> This is a specific area where the semantics are insufficient.
> I think this has been renamed to DUUID.

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

> * renaming of domains
> 
> 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.

> * What controls domains asserting the right uuid?
> 
> 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.

> 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 

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.

> 5) Where is the trust model specified
> 
> We need a clear discussion of the trust model for both documents.

ack.

> 6)  Home directories and URIs
> 
> Will require discussion on the list.

ack.

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

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