[Ietf-krb-wg] Comments on informational model

[Sam Hartman-5]

I have reviewed the informational model document.  I have a lot of
questions, but basically I think the document is ready.  I'm not sure
any changes are required to address my comments.  I do ask about
whethere a lot of things are required.  I don't particularly have a
problem with us requiring them if we've thought that through and
concluded that's OK.  If we never really considered why we were
requiring all these attributes I'd prefer that we do so, but would not
object if we decide that shipping this document efficiently is more
important.




Section 6.1: I'm not entirely sure all the attributes of a principal
need to be required.  What is our rule for requiring attributes.  For
example we require a number of attributes today that not all
implementations track.  How can we argue that these are required
aspects of an information model?  In specific cases we may have
decided that a particular feature is so important that we want to make
people who do not have the attribute non-conforming.



Why are 6.1.1.2, 6.1.1.3 and 6.1.1.5 required?  I don't particularly
have a problem with requiring 6.1.1.3 since everyone supports it, but
I'll note that I cannot come up with an argument why it is mandatory.

Attributes 6.1.1.5-6.1.1.8 require that a KDC maintain state.  Why
have we decided this is a requirement?

Attribute 6.1.1.13: It's unclear what we mean by allowed enctypes.  Is this allowed enctypes when the principal is used as a service?  As a client? Both?

Am I correctly reading the text of 6.1.1.13 to mean that I need not
store this attribute per principal, but instead could simply store a
reference to a policy?  I could presumably have one schema that was
based off of policies and one that actually stored the attributes in a
principal?  I could even have another approach that effectively had
inherented policies, and a principal was in some sense its own policy.
Presumably we would pick one of these approaches to standardize, but
I'm confirming I understand the document.

I want to confirm that I'm understanding the informational model.  My
schema must represent principal name (6.1.1.1 ) and realm name
(6.1.1.14) somehow.  I could represent them as one attribute in my
schema for example in RFC 1964 string format.  Or I could have two
attributes.

What does it mean in section 6.2 that a key
set is MUST NOT be required?  Does it mean that any schema based on
this model MUST NOT require implementation of any attributes that
schema happens to define with regard to the informational model?
Similarly, could we have a realization of this information model where
LDAP is used for representing principals and the set/change password
protocol for managing key sets?  (I.E. no specification of key sets in
Ithe LDAP model)?  I guess we could also have a realization of this
model where the principal and key set are implemented ind an ldap
schema, but key is implemented using set/change password.
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Howard Chu-2]

Sam Hartman wrote:

>
> I have reviewed the informational model document.  I have a lot of
> questions, but basically I think the document is ready.  I'm not sure
> any changes are required to address my comments.  I do ask about
> whethere a lot of things are required.  I don't particularly have a
> problem with us requiring them if we've thought that through and
> concluded that's OK.  If we never really considered why we were
> requiring all these attributes I'd prefer that we do so, but would not
> object if we decide that shipping this document efficiently is more
> important.

I had assumed that the attributes listed had already been considered/debated,
but since you raise the question...

> Section 6.1: I'm not entirely sure all the attributes of a principal
> need to be required.  What is our rule for requiring attributes.  For
> example we require a number of attributes today that not all
> implementations track.  How can we argue that these are required
> aspects of an information model?  In specific cases we may have
> decided that a particular feature is so important that we want to make
> people who do not have the attribute non-conforming.

Agreed, several of these are clearly not *necessary* since KDCs have been
successfully implemented without them. But some of them look *desirable* at least.

> Why are 6.1.1.2, 6.1.1.3 and 6.1.1.5 required?  I don't particularly
> have a problem with requiring 6.1.1.3 since everyone supports it, but
> I'll note that I cannot come up with an argument why it is mandatory.

Good question. Moreover, I find it hard to maintain the distinction between
6.1.1.2/6.1.1.3 and 6.3.1.5/6.3.1.6, respectively. A principal without a key
cannot be used, so it seems that these two sets of attributes are redundant.
(Indeed, I've mapped them to a single pair of ppolicy attributes in the
proposed LDAP schema.)

> Attributes 6.1.1.5-6.1.1.8 require that a KDC maintain state.  Why
> have we decided this is a requirement?

Interesting question. Since LDAP ppolicy already implements these (except for
6.1.1.7, which I added in the latest ppolicy draft to accomdate this
requirement) I didn't really worry about it.

> Attribute 6.1.1.13: It's unclear what we mean by allowed enctypes. Is this
allowed enctypes when the principal is used as a service? As a client? Both?
>
> Am I correctly reading the text of 6.1.1.13 to mean that I need not
> store this attribute per principal, but instead could simply store a
> reference to a policy?  I could presumably have one schema that was
> based off of policies and one that actually stored the attributes in a
> principal?  I could even have another approach that effectively had
> inherented policies, and a principal was in some sense its own policy.
> Presumably we would pick one of these approaches to standardize, but
> I'm confirming I understand the document.

This seems to map the the MIT/Novell krbSupportedEncSaltTypes attribute, but
that's maintained per-realm, not per-principal. It seems to me that all you
want is to be able to specify a default set of enctypes per realm, and
override with a specific set of enctypes that will be used for a given principal.

> I want to confirm that I'm understanding the informational model.  My
> schema must represent principal name (6.1.1.1 ) and realm name
> (6.1.1.14) somehow.  I could represent them as one attribute in my
> schema for example in RFC 1964 string format.  Or I could have two
> attributes.

I still don't see the value of allowing a single principal to reside in
multiple realms. I think it just makes key management harder, since you can
have enctypes that are salted with the realmname.

> What does it mean in section 6.2 that a key
> set is MUST NOT be required?  Does it mean that any schema based on
> this model MUST NOT require implementation of any attributes that
> schema happens to define with regard to the informational model?
> Similarly, could we have a realization of this information model where
> LDAP is used for representing principals and the set/change password
> protocol for managing key sets?  (I.E. no specification of key sets in
> Ithe LDAP model)?  I guess we could also have a realization of this
> model where the principal and key set are implemented ind an ldap
> schema, but key is implemented using set/change password.

I interpreted this to mean the latter. I.e., LDAP would store the other
principal data, but some external keystore could be used for the keysets.

--
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Sam Hartman-5]

>>>>> "Howard" == Howard Chu <hyc@...> writes:

    Howard> Good question. Moreover, I find it hard to maintain the
    Howard> distinction between 6.1.1.2/6.1.1.3 and 6.3.1.5/6.3.1.6,
    Howard> respectively. A principal without a key cannot be used, so
    Howard> it seems that these two sets of attributes are
    Howard> redundant. (Indeed, I've mapped them to a single pair of
    Howard> ppolicy attributes in the proposed LDAP schema.)

You need this distinction because it's semantically important from a
management standpoint.  A user typically cannot update principal
expiration but typically can update an expired key with a new one.
Also, you need this distinction in order to determine what error code
to return in the Kerberos protocol.
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Simo Sorce]

On Mon, 2009-10-26 at 11:06 -0400, Sam Hartman wrote:

> >>>>> "Howard" == Howard Chu <hyc@...> writes:
>
>     Howard> Good question. Moreover, I find it hard to maintain the
>     Howard> distinction between 6.1.1.2/6.1.1.3 and 6.3.1.5/6.3.1.6,
>     Howard> respectively. A principal without a key cannot be used, so
>     Howard> it seems that these two sets of attributes are
>     Howard> redundant. (Indeed, I've mapped them to a single pair of
>     Howard> ppolicy attributes in the proposed LDAP schema.)
>
> You need this distinction because it's semantically important from a
> management standpoint.  A user typically cannot update principal
> expiration but typically can update an expired key with a new one.
> Also, you need this distinction in order to determine what error code
> to return in the Kerberos protocol.

Not sure we are on the same page here.

Just to make sure we are talking about the same things:
6.1.1.2/6.1.1.3 are principalNotUsedBefore/principalNotUsedAfter
6.3.1.5/6.3.1.6 are keyNotUsedAfter/keyNotUsedBefore

It looks to me that all these attributes are administratively set,
either explicitly or, in some cases, implicitly (as part of a password
change that regenerates the keys for example), but never settable by
users.

Correct me if I am wrong but the distinction here is not between
user/admin access, but it is rather between the concepts of principal
and key existence/validity.

Now, re-reading the draft I think you are correct in seeing a
discrepancy between the model and the actual mappings in the proposed
ldap schema.

6.3.1.5/6.3.1.6 should be mapped to pwdStartTime and pwdEndTime
I don't see any problem here.

But 6.1.1.2/6.1.1.3 shouldn't.

Initially I though to map 6.1.1.2 to the creation time but they are
semantically quite different things.

What does the KDC do before the principalNotUsedBefore date?
Just pretend the principal does not exist at all ?
And if so what is the point ?

Although I am not sure if 6.1.1.2 is very useful to be honest.


6.1.1.3 makes a little more sense to me, as it allows you to expire an
account regardless of whatever password changing policies. Why would you
care about expiring the principal itself ? Does the KDC again just
pretend the principal does not exist if the date is beyond 6.1.1.3 ? If
so why is this preferable to having expired keys ?
Is it in a way security relevant ?

In case 6.1.1.2 and 6.1.1.3 are actually useful and not mere constructs
of what the protocol allows then we should probably have a pair of
explicit attributes in the schema.

In case it is actually really important to be able to define these dates
I'd propose the following attribute definitions which are basically
identical to the pwdStartTime and pwdEndTime definitions in the password
policy draft.

( KRBATTR.16
NAME 'principalStartTime'
DESC 'The time the principal becomes valid'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )

( KRBATTR.17
NAME 'principalEndTime'
DESC 'The time the principal becomes invalid'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )


As a side note.
The concept expressed in 6.1.1.3 is something that may make sense in the
password policy draft as well, although there it would be borderline as
it would express something about the account itself not the actual
passwords. But we already have the account lockout there so an account
expiration wouldn't probably too out of place.
But this discussion doesn't belong here except to the extent of reusing
the same attributes if the password policy draft is update to provide
the same concept.

Simo.

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

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Sam Hartman-5]

>>>>> "Simo" == Simo Sorce <ssorce@...> writes:

    Simo> Now, re-reading the draft I think you are correct in seeing
    Simo> a discrepancy between the model and the actual mappings in
    Simo> the proposed ldap schema.

Can we please focus on the information model in this thread, not any
proposed mapping to a data model?
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Simo Sorce]

On Mon, 2009-10-26 at 11:57 -0400, Sam Hartman wrote:
>
> Can we please focus on the information model in this thread, not any
> proposed mapping to a data model?

Sorry, I guess I got carried away by the work on the mapping.

So please disregard the part that deals with the actual mapping and just
reply (if you care) to the questions about 6.1.1.2/6.1.1.3

Simo.

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

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Sam Hartman-5]

>>>>> "Simo" == Simo Sorce <ssorce@...> writes:

    Simo> On Mon, 2009-10-26 at 11:06 -0400, Sam Hartman wrote:
    >> >>>>> "Howard" == Howard Chu <hyc@...> writes:
    >>
    Howard> Good question. Moreover, I find it hard to maintain the
    Howard> distinction between 6.1.1.2/6.1.1.3 and 6.3.1.5/6.3.1.6,
    Howard> respectively. A principal without a key cannot be used, so
    Howard> it seems that these two sets of attributes are
    Howard> redundant. (Indeed, I've mapped them to a single pair of
    Howard> ppolicy attributes in the proposed LDAP schema.)
    >>
    >> You need this distinction because it's semantically important
    >> from a management standpoint.  A user typically cannot update
    >> principal expiration but typically can update an expired key
    >> with a new one.  Also, you need this distinction in order to
    >> determine what error code to return in the Kerberos protocol.

    Simo> Not sure we are on the same page here.

    Simo> Just to make sure we are talking about the same things:
    Simo> 6.1.1.2/6.1.1.3 are
    Simo> principalNotUsedBefore/principalNotUsedAfter 6.3.1.5/6.3.1.6
    Simo> are keyNotUsedAfter/keyNotUsedBefore
Right.

    Simo> It looks to me that all these attributes are
    Simo> administratively set, either explicitly or, in some cases,
    Simo> implicitly (as part of a password change that regenerates
    Simo> the keys for example), but never settable by users.

Ah, my thinking was muddled and you are correct.  I think what I meant
is that a user can change the key not used after time (key expiration)
by performing a password change.  They cannot change it directly.
However typically no action a user can take within the Kerberos
context will deal with principal not used after.  They may be able to
take actions in other contexts (extend their contract, pay more money,
sign up for additional classes, renew an authorization) but those are
outside the scope of this model.

I agree with your comments about mapping.
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Henry B. Hotz]

On Oct 23, 2009, at 3:42 PM, Howard Chu wrote:

> A principal without a key
> cannot be used,


On the contrary, a user principal without a key may be *preferred*  
because the only authentication methods allowed may be PKINIT or OTP.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@..., or hbhotz@...



_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Nicolas Williams]

On Mon, Oct 26, 2009 at 10:13:46AM -0700, Henry B. Hotz wrote:
> On Oct 23, 2009, at 3:42 PM, Howard Chu wrote:
> >A principal without a key
> >cannot be used,
>
> On the contrary, a user principal without a key may be *preferred*  
> because the only authentication methods allowed may be PKINIT or OTP.

Good point!

The informational model had better cover the distinctions between
pre-auth authentication credentials that are set for a principal.  No,
I've not checked thouroughly, but a brief, case-insensitve search for
"pre-auth", "preauth", "pki", "certificate" and so on found nothing.
There are attributes with "credential" in their name, and that is
encouraging, but evidently they are currently related only to passwords
and long-term symmetric keys:

6.1.1.8.  principalLastCredentialChangeTime

   This single valued attribute contains the time and date for the last
   successful change of credential (eg password or private key)
   associated with this principal.

So, I think we need at least to add attributes corresponding to PKINIT,
and probably attributes corresponding to OTP.  And let's not forget FAST
(which combinations are accepted).

Nico
--
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Henry B. Hotz]

On Oct 26, 2009, at 8:48 AM, Simo Sorce wrote:

> Although I am not sure if 6.1.1.2 is very useful to be honest.

A use case was presented at the conference where users could create  
restricted-time client principals for use by cron jobs.  Not my first  
choice for how to do it, but it's a legitimate use.  I could also  
imagine some places wanting to pre-provision users with a known start  
date.

> 6.1.1.3 makes a little more sense to me, as it allows you to expire an
> account regardless of whatever password changing policies. Why would  
> you
> care about expiring the principal itself ? Does the KDC again just
> pretend the principal does not exist if the date is beyond 6.1.1.3 ?  
> If
> so why is this preferable to having expired keys ?
> Is it in a way security relevant ?


An expired password (keys) can be reset by the user.  An expired  
principal is like a terminated employee and can only be altered by an  
admin.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@..., or hbhotz@...



_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Nicolas Williams]

On Mon, Oct 26, 2009 at 10:23:26AM -0700, Henry B. Hotz wrote:

> On Oct 26, 2009, at 8:48 AM, Simo Sorce wrote:
> >6.1.1.3 makes a little more sense to me, as it allows you to expire
> >an account regardless of whatever password changing policies. Why
> >would  you care about expiring the principal itself ? Does the KDC
> >again just pretend the principal does not exist if the date is beyond
> >6.1.1.3 ?  If so why is this preferable to having expired keys ?  Is
> >it in a way security relevant ?
>
> An expired password (keys) can be reset by the user.  An expired  
> principal is like a terminated employee and can only be altered by an  
> admin.

Indeed.  Not only that, but distinguishing between credential expiration
and principal expiration is important: users need to know when their
credentials are set to expire, but they don't necessarily need to know
when their employment will be terminated.

Also, you don't necessarily want to delete a principal, or its keys just
because the user's contract/employment is terminated -- you might
re-hire them later, and then simply re-enable their principal, and if
that happens quickly enough then their credentials should still be
valid.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Sam Hartman-5]

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams@...> writes:
8
    Nicolas> On Mon, Oct 26, 2009 at 10:13:46AM -0700, Henry B. Hotz wrote:
    >> On Oct 23, 2009, at 3:42 PM, Howard Chu wrote:
> >A principal without a key >cannot be used,
    >>
    >> On the contrary, a user principal without a key may be
    >> *preferred* because the only authentication methods allowed may
    >> be PKINIT or OTP.

    Nicolas> Good point!

    Nicolas> The informational model had better cover the distinctions
    Nicolas> between pre-auth authentication credentials that are set
    Nicolas> for a principal.  No, I've not checked thouroughly, but a
    Nicolas> brief, case-insensitve search for "pre-auth", "preauth",
    Nicolas> "pki", "certificate" and so on found nothing.  There are
    Nicolas> attributes with "credential" in their name, and that is
    Nicolas> encouraging, but evidently they are currently related
    Nicolas> only to passwords and long-term symmetric keys:


The current info model does not include this.  Honestly I don't think
we have best practices sufficient to standardize that at this time.
My preference is to handle that in an extension to the information
model at some future point.  Even if you believe we're ready to start
that work now, let's ship what we have: it's extensible.
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Leif Johansson-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sam Hartman wrote:
> I have reviewed the informational model document.  I have a lot of
> questions, but basically I think the document is ready.  I'm not sure
> any changes are required to address my comments.  I do ask about
> whethere a lot of things are required.  I don't particularly have a
> problem with us requiring them if we've thought that through and
> concluded that's OK.  If we never really considered why we were
> requiring all these attributes I'd prefer that we do so, but would not
> object if we decide that shipping this document efficiently is more
> important.

Thank you for your review.

I have one question about your comments about optional vs mandatory
attributes though (which applies to several other posts in this
thread): Have you taken section 3 into account and if so do you
disagree that different instantiations of the model can differ wrt
which attributes are mandatory and optional?

        Cheers Leif

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrl7W0ACgkQ8Jx8FtbMZnclqACZAbXuRKWItbi2O9GNfiWL1TdG
utUAoMC0u7pA9d64aUo2Dang3E3nAHNA
=/jTf
-----END PGP SIGNATURE-----
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Sam Hartman-5]

>>>>> "Leif" == Leif Johansson <leifj@...> writes:

    Leif> Sam Hartman wrote:
    >> I have reviewed the informational model document.  I have a lot
    >> of questions, but basically I think the document is ready.  I'm
    >> not sure any changes are required to address my comments.  I do
    >> ask about whethere a lot of things are required.  I don't
    >> particularly have a problem with us requiring them if we've
    >> thought that through and concluded that's OK.  If we never
    >> really considered why we were requiring all these attributes
    >> I'd prefer that we do so, but would not object if we decide
    >> that shipping this document efficiently is more important.

    Leif> Thank you for your review.

    Leif> I have one question about your comments about optional vs
    Leif> mandatory attributes though (which applies to several other
    Leif> posts in this thread): Have you taken section 3 into account
    Leif> and if so do you disagree that different instantiations of
    Leif> the model can differ wrt which attributes are mandatory and
    Leif> optional?

I think so, but perhaps I'm not understanding it correctly.

What I think section 3 says is that if an attribute is marked MUST,
then a model must include that attribute.  It might be marked optional
in the sense of and ldap schema member.  What I think that means is
that a particular object in the directory might or might not actually
have the attribute present, but the LDAP schema would need to support
the attribute.  My assumption is that an implementation conforming to
the LDAP schema would need to support all the MUST level attributes in
the information model, although of course using any given attribute on
any given directory object might not be needed.

So, there are three things in play here:

* Whether data models must represent an attribute
* Whether an implementation must implement an attribute
* Whether an object must use the attribute.

I'm certainly fine saying that all the principal attributes must be
represented.  I *think* section 3 says more than that.
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Leif Johansson-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sam Hartman wrote:

>>>>>> "Leif" == Leif Johansson <leifj@...> writes:
>
>     Leif> Sam Hartman wrote:
>     >> I have reviewed the informational model document.  I have a lot
>     >> of questions, but basically I think the document is ready.  I'm
>     >> not sure any changes are required to address my comments.  I do
>     >> ask about whethere a lot of things are required.  I don't
>     >> particularly have a problem with us requiring them if we've
>     >> thought that through and concluded that's OK.  If we never
>     >> really considered why we were requiring all these attributes
>     >> I'd prefer that we do so, but would not object if we decide
>     >> that shipping this document efficiently is more important.
>
>     Leif> Thank you for your review.
>
>     Leif> I have one question about your comments about optional vs
>     Leif> mandatory attributes though (which applies to several other
>     Leif> posts in this thread): Have you taken section 3 into account
>     Leif> and if so do you disagree that different instantiations of
>     Leif> the model can differ wrt which attributes are mandatory and
>     Leif> optional?
>
> I think so, but perhaps I'm not understanding it correctly.
>
> What I think section 3 says is that if an attribute is marked MUST,
> then a model must include that attribute.  It might be marked optional
> in the sense of and ldap schema member.  What I think that means is
> that a particular object in the directory might or might not actually
> have the attribute present, but the LDAP schema would need to support
> the attribute.  My assumption is that an implementation conforming to
> the LDAP schema would need to support all the MUST level attributes in
> the information model, although of course using any given attribute on
> any given directory object might not be needed.

That is exactly what I tried to express.

>
> So, there are three things in play here:
>
> * Whether data models must represent an attribute
> * Whether an implementation must implement an attribute
> * Whether an object must use the attribute.
>
> I'm certainly fine saying that all the principal attributes must be
> represented.  I *think* section 3 says more than that.

What do you think section 3 says more that that - it it certainly what
I meant to say!

        Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrl9gkACgkQ8Jx8FtbMZnfeTgCgsgLSWlx2brg5wGrCA27qJDtL
UfwAn0fmS9NeDeYOGEQnRtwFgq7gbmkX
=t16U
-----END PGP SIGNATURE-----
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Simo Sorce]

On Mon, 2009-10-26 at 12:31 -0500, Nicolas Williams wrote:

> On Mon, Oct 26, 2009 at 10:23:26AM -0700, Henry B. Hotz wrote:
> > On Oct 26, 2009, at 8:48 AM, Simo Sorce wrote:
> > >6.1.1.3 makes a little more sense to me, as it allows you to expire
> > >an account regardless of whatever password changing policies. Why
> > >would  you care about expiring the principal itself ? Does the KDC
> > >again just pretend the principal does not exist if the date is beyond
> > >6.1.1.3 ?  If so why is this preferable to having expired keys ?  Is
> > >it in a way security relevant ?
> >
> > An expired password (keys) can be reset by the user.  An expired  
> > principal is like a terminated employee and can only be altered by an  
> > admin.
>
> Indeed.  Not only that, but distinguishing between credential expiration
> and principal expiration is important: users need to know when their
> credentials are set to expire, but they don't necessarily need to know
> when their employment will be terminated.
>
> Also, you don't necessarily want to delete a principal, or its keys just
> because the user's contract/employment is terminated -- you might
> re-hire them later, and then simply re-enable their principal, and if
> that happens quickly enough then their credentials should still be
> valid.

This is true but we can also simply use an "account lock" attribute for
that.
However I thought a bit about 6.1.1.3 and I agree it makes a lot of
sense in case of enterprises with high temporary contractors
turnarounds. This would allow to set the life of the principal to be
exactly the same as the of the contract. Allows to create them in
advance and set termination date to the date the contract terminates,
leaving to a future renewal the issue of extending validity.
This way you have a relative peace of mind knowing temp accounts will
not stay active longer then needed, and lets you "reactivate" them at
will when needed.

This means that 6.1.1.2 should be movable in the future, as it may
indicate a principal will be reactivated, but I think the information
model should state that 6.1.12 should always have a value that is
smaller than that of 6.1.1.3, as it makes no sense for the 6.1.1.2 date
to come after 6.1.1.3 and may indicate misconfiguration. The principal
should be considered disabled if that happens.

Example:
You know that in 10 days contractors X,Y will start and they have
contracts for 30 and 60 days respectively. So you create the principals
but make them valid only starting from the day the contractors are
supposed to start, and X will have its principal expire after 30 days
while Y after 60 days.
After 90 days X is again hired for another 30 days, both attributes are
changed to reflect the new start and end date. Potentially the actual
keys may not be changed or if expired may require a simple password
change with the old contractor X password.


Simo.

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

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Sam Hartman-5]

>>>>> "Leif" == Leif Johansson <leifj@...> writes:

    Leif> Sam Hartman wrote:
    >>>>>>> "Leif" == Leif Johansson <leifj@...> writes:
    >>
    Leif> Sam Hartman wrote:
> >> I have reviewed the informational model document.  I have a lot
    >> >> of questions, but basically I think the document is ready.
    >> I'm >> not sure any changes are required to address my
    >> comments.  I do >> ask about whethere a lot of things are
    >> required.  I don't >> particularly have a problem with us
    >> requiring them if we've >> thought that through and concluded
    >> that's OK.  If we never >> really considered why we were
    >> requiring all these attributes >> I'd prefer that we do so, but
    >> would not object if we decide >> that shipping this document
    >> efficiently is more important.
    >>
    Leif> Thank you for your review.
    >>
    Leif> I have one question about your comments about optional vs
    Leif> mandatory attributes though (which applies to several other
    Leif> posts in this thread): Have you taken section 3 into account
    Leif> and if so do you disagree that different instantiations of
    Leif> the model can differ wrt which attributes are mandatory and
    Leif> optional?
    >>
    >> * Whether data models must represent an attribute * Whether an
    >> implementation must implement an attribute * Whether an object
    >> must use the attribute.
    >>
    >> I'm certainly fine saying that all the principal attributes
    >> must be represented.  I *think* section 3 says more than that.

    Leif> What do you think section 3 says more that that - it it
    Leif> certainly what I meant to say!
    >>
    >> I think so, but perhaps I'm not understanding it correctly.
    >>
    >> What I think section 3 says is that if an attribute is marked
    >> MUST, then a model must include that attribute.  It might be
    >> marked optional in the sense of and ldap schema member.  What I
    >> think that means is that a particular object in the directory
    >> might or might not actually have the attribute present, but the
    >> LDAP schema would need to support the attribute.  My assumption
    >> is that an implementation conforming to the LDAP schema would
    >> need to support all the MUST level attributes in the
    >> information model, although of course using any given attribute
    >> on any given directory object might not be needed.

    Leif> That is exactly what I tried to express.

Ah.  I think I see the confusion here.  Section 3 is silent on whether
an implementation MUST implement a particular attribute.
I'm not sure that's so good.
We have a couple of options

1) The data model and information model are silent on this; leads to interoperability problems.
2) We handle this in the information model.
3) We handle in the data model.

Presumably since we don't currently answer this question in the
information model, we believe we want to put it off to the data model.
Why?  For example, why will the set of attributes that get implemented
be dependent on something like ldap vs netconf?
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Nicolas Williams]

On Mon, Oct 26, 2009 at 03:45:32PM -0400, Simo Sorce wrote:

> On Mon, 2009-10-26 at 12:31 -0500, Nicolas Williams wrote:
> > On Mon, Oct 26, 2009 at 10:23:26AM -0700, Henry B. Hotz wrote:
> > > On Oct 26, 2009, at 8:48 AM, Simo Sorce wrote:
> > > >6.1.1.3 makes a little more sense to me, as it allows you to expire
> > > >an account regardless of whatever password changing policies. Why
> > > >would  you care about expiring the principal itself ? Does the KDC
> > > >again just pretend the principal does not exist if the date is beyond
> > > >6.1.1.3 ?  If so why is this preferable to having expired keys ?  Is
> > > >it in a way security relevant ?
> > >
> > > An expired password (keys) can be reset by the user.  An expired  
> > > principal is like a terminated employee and can only be altered by an  
> > > admin.
> >
> > Indeed.  Not only that, but distinguishing between credential expiration
> > and principal expiration is important: users need to know when their
> > credentials are set to expire, but they don't necessarily need to know
> > when their employment will be terminated.
> >
> > Also, you don't necessarily want to delete a principal, or its keys just
> > because the user's contract/employment is terminated -- you might
> > re-hire them later, and then simply re-enable their principal, and if
> > that happens quickly enough then their credentials should still be
> > valid.
>
> This is true but we can also simply use an "account lock" attribute for
> that.

If you're laying off, say, 20,000 employees, do you think you can
lock them all out at once?  It'd be better to set account expiration
times.

> However I thought a bit about 6.1.1.3 and I agree it makes a lot of
> sense in case of enterprises with high temporary contractors
> turnarounds. This would allow to set the life of the principal to be
> exactly the same as the of the contract. Allows to create them in
> advance and set termination date to the date the contract terminates,
> leaving to a future renewal the issue of extending validity.

Yes.

> This way you have a relative peace of mind knowing temp accounts will
> not stay active longer then needed, and lets you "reactivate" them at
> will when needed.

Exactly.

> This means that 6.1.1.2 should be movable in the future, as it may
> indicate a principal will be reactivated, but I think the information
> model should state that 6.1.12 should always have a value that is
> smaller than that of 6.1.1.3, as it makes no sense for the 6.1.1.2 date
> to come after 6.1.1.3 and may indicate misconfiguration. The principal
> should be considered disabled if that happens.

Sure, but it's not serious: principalNotUsedAfter should win.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Nicolas Williams]

On Mon, Oct 26, 2009 at 03:50:51PM -0400, Sam Hartman wrote:

> Ah.  I think I see the confusion here.  Section 3 is silent on whether
> an implementation MUST implement a particular attribute.
> I'm not sure that's so good.
> We have a couple of options
>
> 1) The data model and information model are silent on this; leads to interoperability problems.
> 2) We handle this in the information model.
> 3) We handle in the data model.
>
> Presumably since we don't currently answer this question in the
> information model, we believe we want to put it off to the data model.
> Why?  For example, why will the set of attributes that get implemented
> be dependent on something like ldap vs netconf?

IMO required-to-implement attrs should be listed in the informational
model.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Simo Sorce]

On Mon, 2009-10-26 at 15:01 -0500, Nicolas Williams wrote:
> On Mon, Oct 26, 2009 at 03:45:32PM -0400, Simo Sorce wrote:

> > This means that 6.1.1.2 should be movable in the future, as it may
> > indicate a principal will be reactivated, but I think the information
> > model should state that 6.1.12 should always have a value that is
> > smaller than that of 6.1.1.3, as it makes no sense for the 6.1.1.2 date
> > to come after 6.1.1.3 and may indicate misconfiguration. The principal
> > should be considered disabled if that happens.
>
> Sure, but it's not serious: principalNotUsedAfter should win.

Still it is a constraint that should be explicitly stated (IMO).

Simo.

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

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg