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

From: Nico Williams <[email-masked]>
Date: Tue, 5 Jul 2011 14:55:17 -0500

On Wed, Jun 29, 2011 at 9:11 AM, Sam Hartman <[email-masked]> wrote:
> The chairs would like to solicit comments on whether the PAD draft is
> ready for us to adopt as a working group draft.
> Please send comments by July 10.

My apologies for my very late review.

I support adoption of this I-D as the basis for a WG work item.

General comments:

 - It's important to acknowledge optimization of authorization data
acquisition as an important aspect of a PAD.

 - It might be useful to have an extension to the AP-REQ (or RFC4121)
exchange so that the service can issue an alternate service ticket
without the PAD (on account of the service committing to storing a
local copy of the PAD for as long as the ticket it issues lives).

Specific comments:

 - I'm not terribly fond of having PAD attributes repeat Ticket fields.

 - Regarding PAD-Short-Domain, we need an identifier of "set of
trusted realms" in which a short-form domainname is useful.  Also, I
don't think it's wise to use short-form domainnames, particularly with
the likely opening of the root zone to arbitrary domainname
registrations(!), though I agree that support for non-FQDN usage is
important in many environments.

 - It'd be nice to take this chance to introduce a session ID
attribute that is copied from the initial Ticket to subsequent Tickets
obtained with that initial Ticket.  A UUID will do.  A more structured
identifier (e.g., KDC IDentifier + local session ID) might be
desirable as well.

 - What is the format of the payload of PAD-Posix-Homedir?  It could
just be a regular path, with local automounter and/or
AFS/NFS/Lustre/SMB providing a global namespace (although only AFS can
provide such a namespace today).

  However we may need to have multiple URIs for homedir.  Indeed, I
suggest the use of URIs for this.

 - PAD-Posix-Shell also could deliver multiple values (think of it as
a user preference of shell, with the first shell on that list that is
locally available and allowed being the one to be selected by the end
system).

 - PAD-Fullname: do we need to have a more structured attribute or set
of attributes?  Think of surname vs. given name...

 - PAD-AlternateNames sounds like another attribute where we should be
using URIs (e.g., mailto: URIs for e-mail).

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

 - PAD-Groups should probably be PAD-Posix-Groups.

 - Do we need support for groups that don't have GIDs?  Think of
netgroups...  (I.e., what "ypmatch ${username}.\* netgroups.byuser"
would say.)

 - ID mapping: if an intermediate or final realm's KDC can re-map IDs
(per section 4.16) we need to have attributes that distinguish the
"home domain of the user" from the "domain that the IDs are valid in".

 - The optional public key signature requires additional work.  The
Kerberos "Checksum" type does not cover pubkey signatures...

 - A full ASN.1 module would be nice.

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

---

From: Shawn Emery <[email-masked]>
Date: Sun, 10 Jul 2011 01:04:02 -0600

> Please send comments by July 10.

Sorry for the late reply...

General:

It would be nice to standardize the interface (C bindings) or provide 
examples for accessing PAC data through standards track interfaces.

There have been implementations of non-standardized interfaces, such as 
gss_inquire_sec_context_by_oid. It would be out of scope for this 
draftto cover a GSS-API like this, but should be considered as a 
complimentary draft.

4.4 PAD-DNS-Domain

     Couldn't you also have multiple domains map to a single realm?

4.6. PAD-Domain-UUID

     uuid_t is 128 bits, shouldn't this be in alignment with uuid* 
functions?
     Providing a reference on how the Domain-UUID is constructed would 
be helpful.

4.7. PAD-Posix-Username

     In general it would be nice to have at least a non-normative 
reference for the Posix attributes.

4.14. PAD-AlternateNames

     Why can't this be more generic for any naming attribute that 
applications can use?

5.1. PAD Format

     Which Host Service Key are you referring to here?:

    o  Optional Host Service Key Signature (for use by trusted services
       on a host)

     What about typed holes for future extensions?

6.1 SignedPricipalAuthorizationData

     Why is the following a SHOULD?:

     Unless otherwise
        explicitly administratively configured, the key SHOULD be found
        by substituting the service name component of the principal name
        of the service with 'host'.

     As services should try to avoid using shared keys such as this.

6.2 GSS-API Authenticator Extension

     Refer to draft-ietf-krb-wg-gss-cb-hash-agility on extension formats.

I think if the attributes can be normalize and the formatting 
clarified/changed then this would be an appropriate draft to adopt.

Editorial:

s/eterogenous/heterogeneous/

In the following sentence I believe that you're referring to S2 not D2:

    Such a PAD structure needs to carry enough authorization information

    such that a decision can be made by service D2 in realm R2 regarding

    the access request originating from the client principal C1 within

    realm R1.

s/posfix/suffix/

s/PAD need to be augment/PAD needs to be augmented/

s/realm as whole/realm as a whole/

Shawn.

---

From: Luke Howard <[email-masked]>
Date: Sun, 10 Jul 2011 10:31:29 +0000

> It would be nice to standardize the interface (C bindings) or provide examples for accessing PAC data through standards track interfaces.

draft-ietf-kitten-gssapi-naming-exts perhaps?

-- Luke

---

From: Simo Sorce <[email-masked]>
Date: Sun, 10 Jul 2011 09:27:34 -0400

On Sun, 2011-07-10 at 01:04 -0600, Shawn Emery wrote:
> There have been implementations of non-standardized interfaces, such
> as gss_inquire_sec_context_by_oid.  It would be out of scope for this
> draft to cover a GSS-API like this, but should be considered as a
> complimentary draft.
> 
> 4.4 PAD-DNS-Domain
> 

This refers to the main domain name in use, others can be available but
they are not relevant for user authorization data.

>     Providing a reference on how the Domain-UUID is constructed would

This is vague as we want to allow easy mapping of Windows Domain SIDs
into this field for interop purposes. So this is literally just a Unique
Identifier, I can change the name if it is felt that using UUID is
confusing.

> reference for the Posix attributes.

I have been asked to refer to RFC 2307 for attributes. I will go thorugh
RFC 2307 before the next draft and verify if the definitions there are
adequate (For example I do not want to force these names to be case
sensitive although implementations are free to treat them in a case
sensitive way if they really, really want to.

>     Why can't this be more generic for any naming attribute that

I am not sure I understand the objection, can you make an example of
what you'd like to use this attribute for ?

>     Which Host Service Key are you referring to here?:

host/fqdn@REALM

>     What about typed holes for future extensions?

Perhaps, but I am not sure we want to make this field too extensible, it
makes creating interoperable implementations harder if not done right.

>     As services should try to avoid using shared keys such as this. 

This is not a shared key, this is useful exactly in the opposite case
where the service key differs from the host key and you cannot trust a
PAD signed by a service key as host. I would make it a MUST if I didn't
already spot cases where an implementation might need to use a different
trusted key (thinking about clusters here).
Keep in mind that this signature is optional, so you can omit it
completely, but if you want to use it you SHOULD provide a signature
based on the host key so that a host trusted service can verify the PAD
independently from the less trusted service receiving and forwarding it.
In environment where host and service keys are the same (like in AD)
this field is useless as it adds no security, so you should just omit
it.

>     Refer to draft-ietf-krb-wg-gss-cb-hash-agility on extension

I'll take a note.

> s/realm as whole/realm as a whole/

Thank you.

Simo.

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

---

From: Simo Sorce <[email-masked]>
Date: Sun, 10 Jul 2011 09:41:57 -0400

>      Refer to draft-ietf-krb-wg-gss-cb-hash-agility on extension

I was looking at this draft and I am going to change mine to conform to
your defined way to added extension but there is one thing that looks at
odds with the conventions otherwise used in the Authenticator.

In draft-ietf-krb-wg-gss-cb-hash-agility you say that the extention type
and length fields must be in big-endian order, but the original fields
in the Authenticator are little-endian. To avoid confusion I think you
should make these fields little-endian too, it looks like that would be
in line with the rest of the format.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Sun, 10 Jul 2011 11:25:29 -0400

> My apologies for my very late review.

My apologies for not replying earlier.

>  - I'm not terribly fond of having PAD attributes repeat Ticket fields.

As far as I can tell the only fields repeated are those necessary to
validate that the PAD is actually correctly bond to the ticket.

> important in many environments.

Keep in mind that this is defined as useful only for 'representation'
purposes. It should not be used for any other task. It is basically only
meaningful within a set of trusting domains. Moreover a KDC can decide
to remove or change this field upon PAD re-validation before including
it into a cross realm TGT or a service ticket.

> identifier (e.g., KDC IDentifier + local session ID) might be

I am not sure what this would be useful for.

> provide such a namespace today).

It is only a local path as defined by the RFC 2307 homeDirectory
attribute. Although I think it may make sense to have a network home
directory path, this attribute is not that.

> suggest the use of URIs for this.

I suggest you propose a completely new attribute to add to the PAD and
justify its use, especially define how it can be used in a cross-realm
trust environment and how it should be treated when the receiving
service is not authorized to access the network resource specified here.
I am not sure I want to add an attribute like this as it goes beyond
what is strictly necessary for a Posix machine to operate but I am
willing to ponder if the benefits largely outweight the need to avoid
feature creep in this standard.

> locally available and allowed being the one to be selected by the end

Shells are usually better defined per system, this attribute should be
considered optional and the default shell defined in the target system
should probably be used in most cases. Although I do not see harm in
redefining this attribute to be multi-valued I have to notice that in
practice it will almost never be used as a multi-valued attribute. In
RFC2307 the loginShell is defined as SINGLE-VALUE and the reason is
simply that in LDAP order is generally not defined for attributes.
So for simplicity's sake I'd prefer to keep this single valued unless
others also feel it would really be better to have this attribute
defined multi-valued and they have a way to use it as multi-valued in
their current or planned implementations.

> of attributes?  Think of surname vs. given name...

I'd like to stay away from dictating the form of this attribute. The
LDAP schema to define these fields is a disaster as it fails to address
all the ways names are given in the world forcing an artificial first,
given, last name format. I'd like to avoid that and leave this field
free form and leave to organizaztions to define how they want to treat
it. This field is informational anyway and primarily used for display
purposes so I don't see the need to strictly defined its format.

> using URIs (e.g., mailto: URIs for e-mail).

Perhaps, but do you have a URI for anything that can go there? If not
what do we do when we need to put in a name that doesn't have a URI
definition available ?

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

> netgroups...  (I.e., what "ypmatch ${username}.\* netgroups.byuser"

Not sure about netgroups, I think the netgroups format makes little
sense and would like to avoid to perpetrate this messed up format.

However I was recently working on non-posix groups in my implementation.
Groups used to control authorization access without polluting the posix
name space (partly sue to legacy platforms that cannot deal with more
than 16 posix groups per user).

I am unsure if we want to actually allow additional groups to be
defined, it is a tempting thing to do. But if we do that we may need to
define an additional per group optional uuid fialed and make the gid
field optional.

Do anyone else see value in something like this ?

> "home domain of the user" from the "domain that the IDs are valid in".

No we don't, the 'home domain of the user' is completely uninteresting
for the target service if the KDC has remapped it.

> Kerberos "Checksum" type does not cover pubkey signatures...

Yes, I would really like some help on this part.

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

Does anyone opposes ASN.1 at this point?

Thanks,
Simo.

---

From: Shawn Emery <[email-masked]>
Date: Mon, 11 Jul 2011 00:23:37 -0600

> draft-ietf-kitten-gssapi-naming-exts perhaps?

Yes, this is what I was implying by standards track interfaces.

Shawn.

---

From: Shawn Emery <[email-masked]>
Date: Mon, 11 Jul 2011 00:23:50 -0600

> Identifier, I can change the name if it is felt that using UUID is

Yes, this would be helpful.

> sensitive way if they really, really want to.

Is there is a reference that could be used that is not experimental?

> what you'd like to use this attribute for ?

Refer to draft-ietf-kitten-gssapi-naming-exts::6. Representation of 
Attribute Names.

>>      Which Host Service Key are you referring to here?:

This should be defined or referenced.

> makes creating interoperable implementations harder if not done right.

We should do it right then.

> this field is useless as it adds no security, so you should just omit

I think this should be clarified in the draft.

Thanks,

Shawn.

---

From: Shawn Emery <[email-masked]>
Date: Mon, 11 Jul 2011 00:23:56 -0600

> in line with the rest of the format.

IMO I don't think that this is an issue and the change would break 
compatibility of at least two known implementations of the protocol.

Shawn.

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Jul 2011 12:26:49 -0500

> validate that the PAD is actually correctly bond to the ticket.

Yes, I understand that.  I'd prefer that we have a cryptographic binding.

Consider how the Authenticator type from RFC4120 parrots fields from
Ticket in addition to having to have its encpart encrypted in the same
session key as appears in the ticket.  Specifically: cname and crealm.
 This means that we can't have the KDC issue tickets with different
cname for the client.  This is very annoying.  We could have had
service principals that do not receive full identifying information
about their clients, but now we can't have that.

I would rather we stop the use of cargo cult-ish validation methods
and instead rely entirely on cryptographic binding wherever possible.

That said, it's possible that a pure cryptographic binding in this
case would be too difficult to implement (because, say, it might
require re-encoding a Ticket without the PAD in order to get a
checksum (Kerberos sense of checksum).  OTOH, a session ID could help
here (see below).

> it into a cross realm TGT or a service ticket.

I'm not sure what you mean by representation.  Can you elaborate on
how the "short" form of a domain name would be used?  Specifically:
would it be used in display representations of names?  In user
provided query syntax inputs?  In log files?

> I am not sure what this would be useful for.

Auditing, for one (so that many tickets could be tied to their
originating INITIAL ticket).

I'd also like a ticket ID as well.

But also see above regarding binding of PAD to ticket.

> feature creep in this standard.

This isn't just about non-POSIX login uses of the PAD.  Consider an
environment where the system where the user is logging in doesn't have
a full automounter map (or access to it) nor a global namespace of any
sort (AFS, ...).  Here the PAD could supply the necessary automount
map entry for the system to provide the POSIX path.

Without this I guarantee you that people will use paths in the form
/net/servername/server-local-path to specify homedir locations -- this
being very much URI-like, but with obnoxious limitations (for example,
the Solaris automounter currently supports only the use of NFS for
/net).

I'd rather we use actual URIs instead of /net/... URI-like paths.

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

> should probably be used in most cases. Although I do not see harm in

New shells come along without, at first, being universally available.
I've seen this movie (in the 90s with ksh, later with bash).  I don't
want to see a remake.

> practice it will almost never be used as a multi-valued attribute. In

It never is, of course.  And a system would have to pick a single
value for local purposes.

> their current or planned implementations.

The fact that RFC2307 (and NIS, ...) has a single value for this is a
problem.  The fact that getpwnam() has a single value for this is not
a problem.  The latter provides a local answer in a (by definition)
homogenous system, while the former provides a global answer in a
heterogeneous system.

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.

> purposes so I don't see the need to strictly defined its format.

Fair enough.  (Note that some systems do try to interpret the GECOs
field...  I think we can safely ignore that.)

> what do we do when we need to put in a name that doesn't have a URI

We can always register new URI schemes.

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

> sense and would like to avoid to perpetrate this messed up format.

I hate netgroups, but they are what we have, and we do use them (in
pam_netgroup, in passwd_compat, ...).

I like the NIS conception of netgroups, which is different from the
documented conception of netgroups.  In NIS innetgr() returns true if
the user is a member of the given netgroup, and so is the host -- NIS
does not look for explicit (user,host,-) triples.

> than 16 posix groups per user).

I'd like that.  But first let's consider (and possibly rule out) the
NIS conception of netgroups.

> for the target service if the KDC has remapped it.

Right, but we need to know unambiguously if the KDC has done that.
Also, we don't want transited realms to do ID mapping.

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

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 12 Jul 2011 17:51:36 -0700

> Does anyone opposes ASN.1 at this point?

I have a personal fondness for ASN.1.  I also do not like the idea of just plopping a binary structure in the ticket and leaving everyone to figure out how to shuffle the byte ordering on their machine.

More objectively, I think this is a Kerberos RFC.  Anyone developing Kerberos code is likely to have access to an ASN.1 compiler.  They, or someone they know, needed it in order to build the code this stuff is being added to, didn't they?
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Jul 2011 22:53:11 +0200 (MEST)

> > Does anyone opposes ASN.1 at this point?

(To avoid confusion, I'm OK.)

> 
> 
> I have a personal fondness for ASN.1.  I also do not like the idea
> of just plopping a binary structure in the ticket and leaving everyone
> to figure out how to shuffle the byte ordering on their machine.
> 
> More objectively, I think this is a Kerberos RFC.  Anyone developing
> Kerberos code is likely to have access to an ASN.1 compiler.

I believe the latter assumption is flawed. 
Has MIT replaced parts of their Kerberos 5 code with something produced 
by an ASN.1 compiler?

We are doing PKI (X.509v3,PKCS#7) without an ASN.1 compiler.

>
> They, or someone they know, needed it in order to build the code
> this stuff is being added to, didn't they?

Nope.  ASN.1 compilers are dispensable and their usefulness is
highly overrated and risks they cause are highly underrated.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Jul 2011 16:55:43 -0500

> Has MIT replaced parts of their Kerberos 5 code with something produced

No, but Heimdal has.  And Heimdal's compiler is FOSS.

It's very difficult to retrofit an ASN.1 compiler into a project that
had hand-coded ASN.1.

> We are doing PKI (X.509v3,PKCS#7) without an ASN.1 compiler.

Most implementors don't use any ASN.1 compilers.

> highly overrated and risks they cause are highly underrated.

Can you expand on the risks?  Thanks,

Nico

---

From: Martin Rex <[email-masked]>
Date: Thu, 14 Jul 2011 00:13:18 +0200 (MEST)

Nico Williams wrote:
> 
> >
> > Nope. Â ASN.1 compilers are dispensable and their usefulness is

The code generated by ASN.1 compilers is going to be used for processing
"untrusted" data from the network and arbitrary peers.

I really prefer to write and review such code myself, rather than
having to review code that is automatically generated.

And if you want additinonal features such as tolerance or intolerance
for specific non-standard behaviour, or support for specific trace/debug
information while parsing you quickly get to a point where doing it
all by yourself amounts to less work and better and more comprehensible
result.

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 13 Jul 2011 16:02:19 -0700

> Has MIT replaced parts of their Kerberos 5 code with something produced 

My understanding is that the MIT code can be built against some OSS ASN.1 compiler now.  I forget which one was mentioned.  Can someone from MIT comment?

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Jul 2011 18:32:55 -0500

> "untrusted" data from the network and arbitrary peers.

Why would one not expect the compiler to expect data to be decoded to
be untrusted?

> all by yourself amounts to less work and better and more comprehensible

Heimdal's compiler has options for generating code compatible with,
e.g., BIT STRING as implemented in Kerberos.

Heimdal's ASN.1 compiler is also very easy to extend (a few weeks ago
I sent Love patches for using 64-bit C integers for suitably
constrained INTEGER types; it was quite simple).

Anyways, no, I don't trust others to write good ASN.1 decoders.  And I
can't write everything myself, and neither can anyone else.

Nico

---

From: Greg Hudson <[email-masked]>
Date: Thu, 14 Jul 2011 00:08:11 -0400

On Wed, 2011-07-13 at 19:02 -0400, Henry B. Hotz wrote:
> My understanding is that the MIT code can be built against some OSS
> ASN.1 compiler now.  I forget which one was mentioned.  Can someone
> from MIT comment?

I don't think so.  We've leaked our own structure definitions into the
library API (and those structures don't always correspond 1:1 to the
ASN.1 sequences), so you'd need a very flexible ASN.1 compiler, or else
a lot of glue code to copy fields between the compiler's C structures
and ours.

But we'd still prefer ASN.1 encoding of data sequences for Kerberos
extensions, in general.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Jul 2011 11:03:18 -0400

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

    Nico> On Wed, Jul 13, 2011 at 3:53 PM, Martin Rex <[email-masked]> wrote:
    >> Henry B. Hotz wrote:
    >>> More objectively, I think this is a Kerberos RFC. Â Anyone developing

    Nico> No, but Heimdal has.  And Heimdal's compiler is FOSS.

    Nico> It's very difficult to retrofit an ASN.1 compiler into a project that
    Nico> had hand-coded ASN.1.

I think the discussion of whether ASN.1 compilers are a good idea is
fairly off-topic for krb-wg and I'd like to ask people to take it off
list.  If someone were using it as an argument either for or against
using ASN.1 as an encoding--for example for the PAD draft--then it might
be on-topic.
However, all the participants have indicated they are comfortable with
ASN.1.
It seems wether implementations use compilers or something open-coded is
not really important for standardization.

Sam Hartman
Kerberos co-Chair

---

From: Sam Hartman <[email-masked]>
Date: Fri, 15 Jul 2011 11:47:11 -0400

Speaking as an individual.
I favor cryptographic binding and removing fields copied from the
ticket.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Sun, 17 Jul 2011 18:53:40 -0400

> Yes, I understand that.  I'd prefer that we have a cryptographic binding.

I know, but doing it that ways makes it much more difficult for an
implementer to independently verify the PAD w/o the rest of the ticket.

I know of difficulties both server side in the KDC and client side, and
given full cryptographic binding doesn't give anything more than a warm
feeling it is the 'right thing to do(TM)' so far I think we should make
implementations simpler.

> about their clients, but now we can't have that.

I fail to see what's the point in the context of the PAD. The PAD is all
about providing identification and authorization material for a specific
principal, it make no sense to have a PAD for anonymous credentials. Or
did I misunderstand what you are saying ?

> and instead rely entirely on cryptographic binding wherever possible.

Me too as long as this doesn't make implementation much more difficult
and this is one such case.

> checksum (Kerberos sense of checksum).  OTOH, a session ID could help

Yes, too difficult for the KDC, but also for clients where you want to
take the PAD and feed it to another process, w/o having to pipe down the
full ticket (including knowledge of how to re-parse it) in order to
validate the PAD.

> provided query syntax inputs?  In log files?

Yes probably all three, the key part being that it is just a shorthand
for a long name that is vetted by the KDC. Admins are responsible for
not causing duplication of short names, within the trusting realms.

I guess we can discuss more on what security recommendations to make wrt
this field.

> But also see above regarding binding of PAD to ticket.

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 ?

> map entry for the system to provide the POSIX path.

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 ?

> /net/servername/server-local-path to specify homedir locations --

This is pretty much to be expected and entirely in the hands of
administrators.

>  this being very much URI-like, but with obnoxious limitations (for example,

Passing in arbitrary URIs also have undesireable side effetcs:
- What if the receiving host does not understand the URI ?
- What if admins on the receiving host want to use only a local home
because this system is not a common one where you should be using your
data ?
- 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 ?

> I'd rather we use actual URIs instead of /net/... URI-like paths.

In some limited, very controlled environments that could be useful, but
because it is not something generally easy/useful to do I'd still like
to make it a separate extension.

> homedir, the other providing location URIs for the homedir.

The only reason I want homeDir is for backwards compatibility reasons to
be honest. Personally I would configure a domain not to provide that
attribute and let it be defined locally on each machine depending on
local configuration.
So, as written above, I think I would like to defer something like a
network home URI to a separate extension.

> I've seen this movie (in the 90s with ksh, later with bash).  I don't

As for homeDir I want the loginShell only for backwards compatible
reasons. In this case too I think a local value should be set and this
(optional) attribute left out in most environments.

> value for local purposes.

How do you do that ?

> homogenous system, while the former provides a global answer in a

Agreed so far.

> it's an obnoxious complication.

It should just be made easy to configure on local systems IMHO.
Expanding the mess by including multiple shells now you have to sort and
filter and wonder what to do if they are not available locally with a
fallback and probably both white-lists and black-lists is not going to
improve the situation IMHO.

> field...  I think we can safely ignore that.)

The gecos field is a separate one, again provided as is for legacy
purposes, and in particular in order to have it built in a way that can
be parsed by those systems. Yet newer system can choose to use the
FullName attribute instead which clearly is just about the Full Name of
the entity logging in.

> We can always register new URI schemes.

I guess this could be done, what are URIs we should use to distinguish
between OpendId and Oauth ?

> supplementary group list (e.g., to deal with the ancient AUTH_SYS 16

Systems with this limitation can decide to remove the primary gid from
the supplementary group list at PAD decoding time.

> pam_netgroup, in passwd_compat, ...).

Not we do not have to, legacy systems may need it, but in one of our
products we are already trying to move away from netgroups (yet we
provide a computed representation for backward compatibility).

It can be done and we can move away so I'd like to avoid carrying this
mess over in newer protocols/standards.

> NIS conception of netgroups.

I am pretty much against it :)

> Right, but we need to know unambiguously if the KDC has done that.

This is true. Otherwise you don;t know if you are receiving conflicting
IDs or translated IDs. Should we have a flag for 'translated'
somewhere ?

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

> I recommend that you use the Heimdal ASN.1 compiler to generate the

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.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Sun, 17 Jul 2011 18:55:10 -0400

On Tue, 2011-07-12 at 17:51 -0700, Henry B. Hotz wrote:
> I have a personal fondness for ASN.1.  I also do not like the idea of
> just plopping a binary structure in the ticket and leaving everyone to
> figure out how to shuffle the byte ordering on their machine.
> 
> Kerberos code is likely to have access to an ASN.1 compiler.  They, or
> someone they know, needed it in order to build the code this stuff is
> being added to, didn't they?

Exactly my thinking.

So from now on I'll consider the matter settled and ASN.1 to be the
description language.

What the encoding ?

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Sun, 17 Jul 2011 19:11:22 -0400

> Yes, this would be helpful.

Ok, what about PAD-UDID (Unique Domain ID) ?

> Is there is a reference that could be used that is not experimental?

I looked into the POSIX.1-2008 standard* next to see if these attributes
are defined well enough to use it as a normative reference.
It looks like they are very loosely defined in there.

* IEEE Std 1003.1-2008 / The Open Group bBase Specifications Issue 7

> Refer to draft-ietf-kitten-gssapi-naming-exts::6. Representation of 

Uhmm you defined some characters as special in that document (space and
':'), but I don;t see any discussion about escaping in case those
characters are part of the actual names as opposed to be just
separators. ANy reason why this is not a problem in that document ?

> This should be defined or referenced.

OK.

> I think this should be clarified in the draft.

OK

---

From: Simo Sorce <[email-masked]>
Date: Sun, 17 Jul 2011 19:12:10 -0400

On Mon, 2011-07-11 at 00:23 -0600, Shawn Emery wrote:
> IMO I don't think that this is an issue

Well I am sure it will be confusing for new implementations.

>  and the change would break 

Sigh, ok.

---

From: Nico Williams <[email-masked]>
Date: Sun, 17 Jul 2011 18:36:10 -0500

> implementer to independently verify the PAD w/o the rest of the ticket.

It'd help to have an understanding of what the API data flows are that
you are planning on.

Let's imagine a GSS acceptor application that extracts the PAD via GSS
naming extensions then passes the PAD to a PAM-like API.  Then having
the principal name appear in the PAD becomes important.  If the GSS
app passes the whole Ticket to the PAM-like API, then having the
principal name appear in the PAD becomes less important.

If you pass a ticket then you need to pass type information too, since
we can imagine other mechanisms using the PAD too.  So I think I see
why you want the PAD to stand alone.

Do I still want a cryptographic binding to the container that bears a
PAD?  I'm not sure.  I'll have to think about it.

But what do we need the cname/crealm in the PAD for?  Whatever
consumes the PAD... what's it do with the cname/crealm in the PAD?

>> [...]

The point was that non-cryptographic bindings have closed doors to us
in the past, so it'd be nice if we could avoid that in the future.

We don't have to know today what we'll want to change in the future.
We need only know what kinds of changes we want to preclude.

>> >> [...]
>> > [...]

How can admins do this in a large forest??

>> >> [...]

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.

AD has a session SID in its PAC, with the session ID component of the
session SID being 64-bit wide.  This is quite useful.  If you were
using SIDs we could add this later.  But you're not using SIDs, so
something like this has to be added now.

> [homedir discussion elided]
>

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.

> This is pretty much to be expected and entirely in the hands of

But it's not good enough because /net is not a universal convention
and because it doesn't support *all* protocols (Solaris' automounter
only supports the use of NFS for /net, for example).

> - What if the receiving host does not understand the URI ?

It ignores it.

> because this system is not a common one where you should be using your

That's local policy -- they'd ignore any other form of homedir info in the PAD.

> access because you have a one way trust anyways ?

You also have this problem in your case.  Note that by having multiple
URIs you can allow the end system to fallback on the first one that
works (which might be a file:/// URI).

> to make it a separate extension.

You're just making assertions.  Please back them up.

> attribute and let it be defined locally on each machine depending on

Why even have a PAD then?  Why wouldn't you say exactly the same thing
about all other attributes in the PAD?

> network home URI to a separate extension.

I don't agree.

> [shell discussion elided]
>

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

>> value for local purposes.

It'd pick the first value from the ordered list in the PAD that is
locally available.  E.g., if the list in the PAD is {"/usr/bin/zsh",
"/usr/bin/ksh", "/bin/ksh", "/bin/sh"}, and zsh is not installed but
ksh is, then the system would select "/usr/bin/ksh" as the user's
shell.

> It should just be made easy to configure on local systems IMHO.

No!  What is the point of the PAD if we keep saying "oh, that
attribute I don't care about, so let's make that local"??  Why
couldn't any one of us say that about *all* the proposed attributes in
the PAD?

I'm not saying that every imaginable attribute must be available in
the PAD.  I'm saying that all the POSIX user attributes should have
useful equivalents in the PAD.

I care much less about shell than I do about homedir, because users
already deal with having to pick a shell from the least common
denominator for all their systems -- there is no simple equivalent for
homedirs.

> improve the situation IMHO.

The list *is* the fallback.  Also, there's no need to explain other
local fallbacks because they are local.

> between OpendId and Oauth ?

The issuer puts in the ones it cares about and the end system uses the
ones it supports.

> 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 am pretty much against it :)

Is that because you have netgroups?  Or just the NIS simplification of them?

Incidentally, the simplest thing to do to replace netgroups mostly
backwards compatibly is to consider user and host memberships as
distinct -- not as individual tuples.  Then innegtr() is trivial to
implement.

> IDs or translated IDs. Should we have a flag for 'translated'

We need to know the namespace that the IDs are from (whether they were
mapped or not is irrelevant).  If the namespace of some ID is not the
local namespace of POSIX IDs, then ID mapping is required, and knowing
the namespace the ID came from may be (is!) essential to the ID
mapping function.

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

Nico

---

From: Sam Hartman <[email-masked]>
Date: Sun, 17 Jul 2011 19:49:17 -0400

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

    Simo> What the encoding ?

Speaking with my chair hat on.

I still need to go through all the mail to confirm that we have a rough
consensus to adopt this work.  Howeverit's clear from the mail I have
read that we do not have a rough consensus surrounding the semantics or
specifics of what data gets encoded. If we adopt the work this will
explicitly be called out as an area where there is no presumption of
consensus.

One of our jobs is to have the necessary discussions to build a
consensus on this issue.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Sun, 17 Jul 2011 18:55:10 -0500

> So from now on I'll consider the matter settled and ASN.1 to be the

We should settle on DER for the same reason that we're settling on
ASN.1 as the specification syntax.

We don't have a lot of choices here anyways.  BER?  BER has
canonicalization issues.  CER?  No reason to go with that, and it'd be
confusing.  XER?  Please no!  PER?  PER would be fine, except that we
don't have tools for PER nor as much experience with it as with DER.
That really only leaves DER.

Question: what had your original plan been?  To use XDR?  ASN.1/DER?
Something else?  FWIW, I could support the use of XDR, but I prefer
ASN.1/DER.

Nico

---

From: Luke Howard <[email-masked]>
Date: Mon, 18 Jul 2011 08:30:15 +0000

> Something else?  FWIW, I could support the use of XDR, but I prefer

Perhaps NDR or something similar? (NDR-lite a la NegoExts?)

Just speculating... :-)

-- Luke

---

From: Simo Sorce <[email-masked]>
Date: Mon, 18 Jul 2011 08:04:08 -0400

> Something else?  FWIW, I could support the use of XDR, but I prefer

My original plan was ASN.1/DER as that's what is used elsewhere in
Kerberos.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Mon, 18 Jul 2011 08:04:23 -0400

> Perhaps NDR or something similar? (NDR-lite a la NegoExts?)

No thanks.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Mon, 18 Jul 2011 08:46:14 -0400

> why you want the PAD to stand alone.

This is the main reason, yes.

> consumes the PAD... what's it do with the cname/crealm in the PAD?

You mean in Buffer 0 ?
I guess I forgot to drop them when the realm and the name have been put
in the PDA-DATA sequence. And now that I look at it 6.1 misses the
timestamp in the PAd-DATA sequence as defined in the schema shown in 5.

> in the past, so it'd be nice if we could avoid that in the future.

I understand that.

> We need only know what kinds of changes we want to preclude.

Or to allow ...

> How can admins do this in a large forest??

Carefully ? ;-)

I added the short name only bacause it is used widely in Windows
environments (also know as NEtBios name there). But I guess we can drop
it and let local systems be configured with shorter aliases if admins so
choose.

> Auditing is one.  Today there's no easy way to link tickets to TGTs.

Why would that be important ?

> services to a single initial TGT.  That's also annoying.

Why is that annoying, in what case do you need that ?

> something like this has to be added now.

I have mentioned that we may want to add an optional unique ID to group
definitions, in case we want to have groups that do not have GIDs
expressed in the PAD. That could be reused as a session ID using a
special group name. But I am still unsure we really need it.
After all auditing can be already done matching the kdc logs and the
ticket timestamps in most cases.

Is there any other reason but auditing ? Anyone else want to chime in ?

> to be included.  Services should use the first URI that works for

Ok, if nobody else complains I will add a homeURI multi-valued
attribute.

> only supports the use of NFS for /net, for example).

I would like say that limitation of some platforms do not concern me,
but that wouldn't be true :)

> You also have this problem in your case.

Not really because in my case I am only providing the system with a
local path. I am not implying what the system should mount on that path.
Your URI adds this implication. Which many (most?) system won't be able
to follow, at least initially, some ever.

>   Note that by having multiple

So we need a ordered list here too ?

> You're just making assertions.  Please back them up.

As I said a few times on the conf call and in mail I want to make the
PAD carry enough information to represent POSIX user/group database
attributes and not much more than that. Otherwise everyone will want to
add their pet attributes and consensus will be more difficult to
achieve. This homeURI thing will have to be optional, and we must make
it ok to completely ignore it, making it useless stuff we carry around
in most cases. It will also need additional wording on filtering from
the KDC (people may not want to disclose their network topology to other
realms etc... so filtering is necessary, etc..

> about all other attributes in the PAD?

Because some attributes are necessary to share between different
systems, uig, gid and names are absolutely necessary for 2 machines to
access the same remote file systems (or local file systems on portable
drives) and make sense of IDs there.

> > network home URI to a separate extension.

Ok, if nobody else object I'll add an optional homeURI attribute.

> except for the fact that we don't need URIs for shells :)
[..]
> ksh is, then the system would select "/usr/bin/ksh" as the user's

The more I think of this the less I like it. It requires user access to
the central directory to set the preferred set of shells (something not
available today), and then it still require systems to fallback locally
to what they ultimately have available anyways.

Unless someone else have strong feelings for adding a list of preferred
shells I am against it.

> couldn't any one of us say that about *all* the proposed attributes in

A PAD is necessary to carry around identity/authorization information,
homedir and shell are there because they are legacy posix attributes for
user databases.
The PAD is not a way to carry around user preferences, that's something
to be deferred to other tools IMHO (puppet, cfenging, shared homedirs,
group policies, ...).

> useful equivalents in the PAD.

I want posix attributes not 'equivalents' unless there are very good
reasons to expand the scope of an attribute.

Although I do not like too much the homeURI idea I can agree to that
because home directories carry around a lot of user information and
potentially authorization information (thinking about ~/.ssh for
example).

But the preferred shell does not carry any identity/authorization
information so I see it out of scope here.

> denominator for all their systems -- there is no simple equivalent for

Yes, that's why I am will to compromise on home dirs but not on shells
for now.

> The issuer puts in the ones it cares about and the end system uses the

ok, I'll make them into URIs, I bet people will give a damn and just use
this field as a mechanism:name pair, I am fine with that.

> primary group.  Will we, or won't we have that?  And if we will, how?

username: foo
uidnumber: 123
gidnumber: 123
...
{
 ...
 ,
 groupname: foo
 gidnumber: 123
 [uuid: 121212121212?]
 ,
 ...
}

> Is that because you have netgroups?  Or just the NIS simplification of them?

It's because I hate netgroups, I think they are limiting and I *really*
do not want to put triplets in the PAD. And if we are just putting in
group names all you really need is a group 'type'/'uuid' field and you
can do your own mapping to netgroups in your implementation without
having to mention netgroups in the PAD specification.

> mapped or not is irrelevant).

Ok I think that's why I initially left the PAD-Realm attribute in. I
think it should signal what realm this information applies to.

So if user@REALM1 comes in and PAD-Realm is set to REALM2, then REALM2
clients know the KDC already mapped IDs and do not need to do any
additional mapping.

If PAD-Realm is still REALM1 instead then services need to check in
their configuration if they need to act (and how) on the information
carried by the PAD.

>   If the namespace of some ID is not the

Yes it is.

> lightweight on the [transited realms'] KDC(s)".

Ok, so your position is that the document should state that ID mapping
should not be performed when cross realm TGTs are released ?
We still need to allow a KDC to filter out information it doesn't want
to make available to the other realm, so we need to distinguish between
filtering and mapping explicitly.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Mon, 18 Jul 2011 09:02:23 -0400

> information so I see it out of scope here.

I should have said a *list* of, user set, preferred shells does not
carry useful identity/authorization information.

A shell that is dictated by admins can be seen as a authorization tool,
for example admins may want to set a restricted shell on some accounts
(guests, temporary, etc...).

Simo.

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 Jul 2011 10:21:07 -0500

OK.

> timestamp in the PAd-DATA sequence as defined in the schema shown in 5.

No, I mean PAD-Realm and PAD-Principal.  I suppose if your passing
PADs outside the bearing Ticket then you probably want these two
attributes, but I'm not sure why (to perform some sort of
authorization check?).

>> We need only know what kinds of changes we want to preclude.

That's easy: don't make this extensible.  But if you want
extensibility then you need to think about what might be precluded by
various parts of the design.

> it and let local systems be configured with shorter aliases if admins so

I don't mind this attribute if it comes with either or both of two
things: a) a name for the namespace that the short-form domain is in
(think of this as "forest name"), b) there is additional security
considerations text effectively recommending that this not be used for
anything other than short-form displays (specifically this must not be
used in query syntaxes and should not be used in log entries).  IOW,
I'm concerned about accidental aliasing.

> Why would that be important ?

Tracking actions is a critical part of auditing and forensic analysis.

You could object that Kerberos should have had session IDs, and that
session IDs should be added externally to the PAD.  However, if there
were a session ID in Tickets you'd still want that to also be in the
PAD if you pass the PAD around without its Ticket enclosure.

> ticket timestamps in most cases.

Timestamps don't allow one to track actions to a compromised session.
Alternatively, they do not allow one to weed out uninteresting events.

> Is there any other reason but auditing ? Anyone else want to chime in ?

That's pretty much the main reason, yes.

(Solaris auditing has a session ID concept.  So does MacOS X's.
Windows' session ID is even better because it's larger and thus less
local.  What about Linux?  Near as I can tell Linux auditing has a
session ID concept as well.  The point: if session IDs are not in
POSIX (they aren't), they ought to be because they are widespread
enough.)

> Ok, if nobody else complains I will add a homeURI multi-valued

Anyone else?

> but that wouldn't be true :)

:)

> local path. I am not implying what the system should mount on that path.

But you agree that folks will use /net -- a form of URI.

> Your URI adds this implication. Which many (most?) system won't be able

Not so.  It adds information that the end system may choose to ignore.

> to follow, at least initially, some ever.

But you don't know that.

That's another thing: specifying a local path as the home directory
strikes me as inappropriate since it could be used to assign an
inappropriate location as the home directory.  The end system should
be allowed to ignore the homedir, to pick an alternate one, or even to
translate it in some way -- and here URIs make the translation much
easier.

> So we need a ordered list here too ?

It should be ordered, yes.

> attributes and not much more than that. Otherwise everyone will want to

Home directory appears in the POSIX passwd(4) db.  And in practice
people combine this with the automounter, which has its own DB.

> realms etc... so filtering is necessary, etc..

I've not asked for any non-POSIX attributes yet other than session ID
(and even then, there's a local analog of session ID on most OSes,
including Linux, I believe).

I have no problem with the additional text you think will be needed.

> drives) and make sense of IDs there.

Not really.  If the remote filesystem is in the same home domain as
the user's then the filesystem should be able to figure everything out
on its own.  If the filesystem is elsewhere you can just dynamically
assign a UID and GID to the remote user.  This is enough for ACLs
(that mention users more than groups) to work.

Sure, of course it helps to have group membership information -- it
makes it much easier to manage ACLs.

And what if the user's homedir is the filesystem that the user wants
to access?  They could just memorize the URI to it...  But that's
hardly a user-friendly thing to do.

> to what they ultimately have available anyways.

Huh?  Not at all.  First of all, whether sysadmins want to allow
chsh(1M) to work is up to the admins.  Second, there's a list of
approved shells that's used to control what a user can set their shell
to.  Third, where the user can't set their own shell they can ask the
sysadmins to do it for them.  At worst the user can choose from a list
with exactly one shell on it.

> to be deferred to other tools IMHO (puppet, cfenging, shared homedirs,

I'm OK with not adding things that aren't already in POSIX DBs or that
shouldn't be in POSIX.

You think only of authorization, but I think of name service
optimization as well.  To me name service optimization is an important
aspect of the PAD.

> information so I see it out of scope here.

Sure it does!  What if the shell is a restricted shell?  Or a
restricted menu system?

> this field as a mechanism:name pair, I am fine with that.

But PAD-AlternateNames is not POSIX!  What's the world coming to?!

;)

> having to mention netgroups in the PAD specification.

I never said anything about triplets.  I hate that too.  Just netgroup
names.  Think of the NIS netgroups.byuser map entries...

> think it should signal what realm this information applies to.

That works for me.

> clients know the KDC already mapped IDs and do not need to do any

Sure.  Do we want to retain an indication of what the original realm
was?  (For, e.g., auditing purposes.)  I would.

> should not be performed when cross realm TGTs are released ?

I think in general we want the transited KDCs to only filter out or
add things, but ID mapping in transit probably adds nothing of value
(since the end system/realm will still have to do ID mapping).  But
I'm not against transited realms doing ID mapping (it may add no
value, but it doesn't subtract value either).

> filtering and mapping explicitly.

Absolutely.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Jul 2011 11:38:25 -0400

>> information so I see it out of scope here.

    Simo> I should have said a *list* of, user set, preferred shells
    Simo> does not carry useful identity/authorization information.

    Simo> A shell that is dictated by admins can be seen as a
    Simo> authorization tool, for example admins may want to set a
    Simo> restricted shell on some accounts (guests, temporary, etc...).

<hat role="individual"/>

I guess.  Another argument is that the information necessary to
provision the account on a system--the information necessary for an
authorized user to actually use their authorization--needs to be part of
this.

In the Moonshot context we're finding that people want to have enough
information to auto-create a shell account as a side effect of gss
authentication.  So, we need all the information necessary to do that
available as name attributes.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Mon, 18 Jul 2011 11:53:17 -0400

> attributes, but I'm not sure why (to perform some sort of

PAD-Realm and PAD-Principal are in buffer 0, and I think they were left
there by mistake, as the principal+realm is already available in
PAD-DATA which is the thing that get signed and therefore necessary as
well.

> I'm concerned about accidental aliasing.

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.

It allows also to build usernames that do not conflict with local ones.
If you have a user simo in both REALM1 and REALM2 you can simply make
sure no conflicts arise by prefixing the trusted realm names witrh the
short name: REALM2-simo != simo

It means REALM2 must be unique within all trusted realms of course, and
I am more than willing to add a paragraph on that in the security
considerations.
One thing that could help avoiding issues is to allow the KDC to
arbitrarily change this name so that it can detect potential clashes and
map it to a different name if needed.

> PAD if you pass the PAD around without its Ticket enclosure.

Ok, I guess adding a session ID can be done, but how do you tie it to a
ticket ? Should the session ID be always preserved intact ? Or should it
be regenerated if the PAD is filtered/changed in any way ?

> Alternatively, they do not allow one to weed out uninteresting events.

Ok.

> POSIX (they aren't), they ought to be because they are widespread

Should this session ID just a random number ?
Or does its creation need to follow some rule ?

> Not so.  It adds information that the end system may choose to ignore.

A matter of perspective I guess :)
But given you say it is something that can be ignored I hope you agree
this attribute will be optional and can be missing ?

> translate it in some way -- and here URIs make the translation much

Yes, I think we may want to add text that this is only a suggestion and
is here mostly due to legacy reasons, but the client is always allowed
to change it.

Of course if you change it and then still mount the user's home on it
any misbehavior is the admin fault. (unfortunately I've met apps that
would store the full user's home dire path in the config files and then
go crazy if the user homedir is renamed ... and that's mostly why you
want to carry around the local path ...).

> It should be ordered, yes.

Ok.

> people combine this with the automounter, which has its own DB.

Not on any laptop I have ever seen :)
On servers it is more common, but I have seen many that just use
pam_mkhomedir and give you a local, non shared, home dir.

> including Linux, I believe).

Well the home URI is not something defined in the POSIX user database definition.

> I have no problem with the additional text you think will be needed.

Ok.

> (that mention users more than groups) to work.

A lot of 'if's in here ... I know this could be done, but in the
POSIX/Unix world we are not there yet unfortunately.

> makes it much easier to manage ACLs.

Without group membership info you can't evaluate ACLs properly.

> hardly a user-friendly thing to do.

User friendliness though is not something I am overly concerned with.

> with exactly one shell on it.

Ok, I think I can let this attribute to be multivalued, but leave
implementations free to never support more than one value completely
ignoring any but the first one if they so wish.

> I'm OK with not adding things that aren't already in POSIX DBs or that

Not DBs in general, I am restricting myself to the user and group
databases and nothing else.

> optimization as well.  To me name service optimization is an important

Please elaborate.

> Sure it does!  What if the shell is a restricted shell?  Or a

See my other email.

> But PAD-AlternateNames is not POSIX!  What's the world coming to?!

True, but it is needed in order to be able to match a different user
identifier. But I am willing to remove it if people feels it is not
appropriate.

> names.  Think of the NIS netgroups.byuser map entries...

Ok then we are back to discussing if generic additional (non-posix)
groups should be supported. This means making the gidnumber of a group
optional and adding another optional Unique identifier so that renames
can be properly accounted for on clients that cache information.

Would that be ok ?

> > think it should signal what realm this information applies to.

Ok, taking note to remove principal, keep realm and add explanation
about what the realm name represents here: "Realm for which the
information makes sense w/o additional mapping being required"

> was?  (For, e.g., auditing purposes.)  I would.

The original realm is in the PAD-DATA where it forms the complete
principal name.

> value, but it doesn't subtract value either).

Ok, will add language to that end.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Mon, 18 Jul 2011 11:53:59 -0400

> available as name attributes.

That is goal n.1 of the PAD.

Simo.

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 Jul 2011 11:12:19 -0500

> is much more compact for users.

Yes, and I don't mind that at all.  I mind accepting a realm's
conception of its short-form name.  The only one deciding what
short-form to use should be either the end system or its realm.

> I am more than willing to add a paragraph on that in the security

Not just security considerations.  I think we must say that the last
realm MUST decide what the crealm's short-form name is, if any.

> map it to a different name if needed.

Exactly.  Do that I'm fine with this :)

> be regenerated if the PAD is filtered/changed in any way ?

It should always be preserved intact.  It should be a largish
randomly-generated session ID assigned by the KDC that issues the
initial TGT for the given client principal.

> this attribute will be optional and can be missing ?

Right.

> Not on any laptop I have ever seen :)

Certainly on desktops in enterprises.  As for laptops, it varies.
I've seen usages where when one VPNs in then one also gets access to
one's enterprise homedir automatically.  And with caching filesystems
and/or bi-directional sync, it should be possible to have the same
homedir on a latop and on the enterprise.

> Well the home URI is not something defined in the POSIX user database definition.

POSIX is local only.  So we've technically already left the realm of
POSIX.  It is precisely because of this that we need to tweak the
model somewhat.  ID mapping?  Yeah, that's *not* POSIX.  But you want
to pretend we have POSIX, so you want whatever information in this PAD
 that is needed in order to do so.  Well, home directory is one of
those POSIX attributes that's hard to deal with in a networked,
heterogeneous environment, if all you have is a path.

> Without group membership info you can't evaluate ACLs properly.

Not true: you'd have to add users to ACLs directly.  But it'd work.

>> optimization as well.  To me name service optimization is an important

The PAD allows the end system to avoid having to do name service calls
about the user in question.  That's an optimization, particularly if
the name service lookups done by the KDC(s) are done once
per-TGT/x-realm-TGT.

>> Sure it does!  What if the shell is a restricted shell?  Or a

I don't see anything there about this.  What did I miss?

> identifier. But I am willing to remove it if people feels it is not

I was being facetious :)

> can be properly accounted for on clients that cache information.

In Windows, and in Unix, security and non-security groups have
distinct namespaces.

Nico

---

From: Simo Sorce <[email-masked]>
Date: Mon, 18 Jul 2011 12:21:04 -0400

> In Windows, and in Unix, security and non-security groups have

So what do you propose ?

Simo.

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 Jul 2011 11:28:18 -0500

>> In Windows, and in Unix, security and non-security groups have

A separate list of non-group(4) group memberships.  (Separate list
because separate namespaces.  It could be one list with a bit for each
group indicating the namespace it belongs to, and then the GID being
absent in the non-security group namespace.)

I'd call those "netgroups".  Nothing at all about "netgroup triples"
need be said.  This implies NIS netgroup semantics, but that's the
only semantics that's any good.  (NIS netgroup semantics:
innetgr(some_user, some_host) -> if (innetgr(some_user, NULL) &&
innetgr(NULL, some_host)) then true.)

Nico

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Jul 2011 12:39:42 -0400

>> provision the account on a system--the information necessary for
    >> an authorized user to actually use their authorization--needs to
    >> be part of this.
    >> 
    >> In the Moonshot context we're finding that people want to have
    >> enough information to auto-create a shell account as a side
    >> effect of gss authentication.  So, we need all the information
    >> necessary to do that available as name attributes.

    Simo> That is goal n.1 of the PAD.

Again, as an individual, not a chair, I think that makes list of shells
in scope.
You may not agree with the idea, you may not think it is worth the
complexity.
However, from a scope standpoint, the reason you want a list of shells
is so you can provision the account.

Again, I'm not advocating the feature. I'm just disagreeing with one
possible objection.

    Simo> Simo.

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

---

From: Luke Howard <[email-masked]>
Date: Mon, 18 Jul 2011 16:46:26 +0000

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

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 Jul 2011 11:47:10 -0500

> Again, I'm not advocating the feature. I'm just disagreeing with one

This also brings into scope anything else that the user's home realm,
transited realms, and the service's realm might add that helps the end
system "provision the account".

That could include such things as a thumb image of the user's choice
(e.g., a head shot), any sort of user "profiles" (e.g., what kind of
user the user is, and/or profile in the sense of Solaris RBAC), MAC
label set/range, and so on.  Extensibility clearly helps.

One thing about extensibility: it needs to be possible to filter out
elements that a KDC doesn't understand.  (And it might be desirable to
make KDCs configurable regarding specific types of elements they don't
support.)

Extensibility here would be very simple: just a plain typed hole will
do, with a specification-required registry of types.  Alternatively
use SAML :)  A criticality field might be desirable, but I don't think
one is necessary.

Nico

---

From: Simo Sorce <[email-masked]>
Date: Mon, 18 Jul 2011 13:06:55 -0400

On Mon, 2011-07-18 at 16:46 +0000, Luke Howard wrote:
> 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.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Mon, 18 Jul 2011 13:20:22 -0400

> absent in the non-security group namespace.)

That's what my proposal achieves, gid is optional and unique identifier
is added. The unique identifier is up to you to define in your sue
cases. It can be structured to define a type. If your identifiers carry
type information you can have as many "name spaces" as you want.

I see no need to add a different attribute to separate posix and
non-posix groups, the lack of gid is already quite clear indication this
is not a posix group.

> I'd call those "netgroups".

I wouldn't. If you want additional stuff let's make it generic enough
anything can go in. In the freeipa project for example we have many
group types, HBAC groups, host groups, legacy netgroups, etc...

I would call them simply non-posix groups. Implementations are then free
to choose how to use them.

>   Nothing at all about "netgroup triples" need be said.

What luck! :)

> This implies NIS netgroup semantics, but that's the
> only semantics that's any good.

No, they are not the only good semantics and I do not want to restrict
or hint at NIS netgroups as what these groups should be used for.

If we want to add non-posix groups then we should make this generic
enough that any kind of group can be specified.

So I thin I'll propose something like this:

Group {
  name,
  type,
  id,
}

Where name is the group name, names need to be unique only within the
same type.

Type defines the group type, it is an OID-like type, but in order to
avoid wasting space we should probably make it down to 2 components:
org.type, we will need to define the value for 'posix group' (I suggest
0.0), and probably the OID for 'netgroup' (0.1) ?.

I would like to have it like org.type, so that people can freely
experiment without risking collisions once they get an org number.
I would suggest using the same number they get from IANA for OIDs to be
good enough. And would avoid having to set-up a whole new registry.

Id, the optional ID, which is the Gid for 'posix groups', can be null
for netgroups I guess, but a netgroups with the Id set should not be
considered an error.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Mon, 18 Jul 2011 13:23:15 -0400

> non-posix groups, the lack of gid is already quite clear indication this

Of course I changed my mind later on. We probably want to separate Id
from type so that implementers can agree/reuse types. This will help
interoperability between implementations.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 19 Jul 2011 19:18:08 -0700

> did I misunderstand what you are saying ?

AFS has a defined mapping for unknown/unauthenticated users.  I think there is also provision for id's from realms which you refuse to assign corresponding local id's.