Subject: [Ietf-krb-wg] Comments on informational model

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Oct 2009 17:31:26 -0400

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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Fri, 23 Oct 2009 15:42:44 -0700

> object if we decide that shipping this document efficiently is more

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

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

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

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

> schema for example in RFC 1964 string format.  Or I could have two

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.

> 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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Oct 2009 11:06:11 -0400

>>>>> "Howard" == Howard Chu <[email-masked]> 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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Mon, 26 Oct 2009 11:48:51 -0400

> 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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Oct 2009 11:57:45 -0400

>>>>> "Simo" == Simo Sorce <[email-masked]> 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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Mon, 26 Oct 2009 12:10:18 -0400

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Oct 2009 12:53:09 -0400

>> 
    >> 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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 26 Oct 2009 10:13:46 -0700

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.
[email-masked], or [email-masked]

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 26 Oct 2009 10:23:26 -0700

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

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Oct 2009 12:15:23 -0500

> 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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Oct 2009 13:41:04 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
8
    Nicolas> On Mon, Oct 26, 2009 at 10:13:46AM -0700, Henry B. Hotz 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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Oct 2009 12:31:42 -0500

On Mon, Oct 26, 2009 at 10:23:26AM -0700, Henry B. Hotz 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 ?
> 

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

---

From: Leif Johansson <[email-masked]>
Date: Mon, 26 Oct 2009 19:41:49 +0100

> object if we decide that shipping this document efficiently is more

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Oct 2009 15:15:27 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> 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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Mon, 26 Oct 2009 20:18:33 +0100

> any given directory object might not be needed.

That is exactly what I tried to express.

> 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

---

From: Simo Sorce <[email-masked]>
Date: Mon, 26 Oct 2009 15:45:32 -0400

> that happens quickly enough then their credentials should still be

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.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Oct 2009 15:50:51 -0400

Leif> Sam Hartman wrote:
    >> >> 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.
    >> 
    >> 
    >> * 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!
    >> 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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Oct 2009 15:01:00 -0500

> This is true but we can also simply use an "account lock" attribute for

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.

> leaving to a future renewal the issue of extending validity.

Yes.

> not stay active longer then needed, and lets you "reactivate" them at

Exactly.

> should be considered disabled if that happens.

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

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Oct 2009 15:13:09 -0500

> be dependent on something like ldap vs netconf?

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

Nico

---

From: Simo Sorce <[email-masked]>
Date: Mon, 26 Oct 2009 16:46:38 -0400

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

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

Simo.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Oct 2009 15:51:39 -0500

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

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

---

From: Leif Johansson <[email-masked]>
Date: Mon, 26 Oct 2009 22:22:13 +0100

> We have a couple of options

Actually it isn't. Section 3 says that RFC2119 terms apply to
implementations _of the specification_ - i.e data models - not instances
- - i.e if an attribute is REQUIRED in the model then it MUST be supported
by all implementations

The model IS silent on weather a particular attribute MUST/SHOULD/MAY
be OPTIONAL or REQUIRED by a particular implementation.

Adding that dimension to the model might be a good idea but it
hasn't been discussed before.

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Oct 2009 18:01:14 -0400

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

    Leif> Actually it isn't. Section 3 says that RFC2119 terms apply
    Leif> to implementations _of the specification_ - i.e data models
    Leif> - not instances - i.e if an attribute is REQUIRED in the
    Leif> model then it MUST be supported by all implementations

    Leif> The model IS silent on weather a particular attribute
    Leif> MUST/SHOULD/MAY be OPTIONAL or REQUIRED by a particular
    Leif> implementation.

I'd be happy resolving my comments by a sentence in section 3 that
says whether an implementation must implement an attribute is deferred
to data model specifications.  I read section 3 as saying the info
model talked about what data models and implementations must do, but
not what administrators must use.

I'd also be happy taking Nico's approach and actually adding that
here.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Mon, 26 Oct 2009 15:03:08 -0700

> should be considered disabled if that happens.

Actually that's why I wrote exactly that in the LDAP ppolicy draft: setting 
the start date >= end date will disable, so there wasn't any real need for an 
"account lock" attribute.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 26 Oct 2009 23:25:56 +0100

> not what administrators must use.

OK I think we need to clean up the terminology :-)

By implementation I think I mean what you mean by data-model - as in
"implementation of this specification, i.e a data-model relative to
this information model".

Section 3 talks states that this specification only talks about
data-models relative to this information-model and nothing else.

> I'd also be happy taking Nico's approach and actually adding that

As in adding language to the attribute definitions stating weather
they MUST/SHOULD/MAY be OPTIONAL or MANDATORY in data-models?

I am not sure I favor either approch right now.

	Cheers Leif

---

From: Simo Sorce <[email-masked]>
Date: Mon, 26 Oct 2009 19:07:49 -0400

> "account lock" attribute.

Yes but that applies only to password (keys) validity start/end date.
We need to add the same sort of wording for principal validity start/end
dates.

Simo.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Oct 2009 20:53:58 -0400

Leif> Sam Hartman wrote:
    >> >> Ah.  I think I see the confusion here.  Section 3 is silent
    >> on >> whether an implementation MUST implement a particular >>
    >> 
    >> I'd be happy resolving my comments by a sentence in section 3
    >> that says whether an implementation must implement an attribute
    >> is deferred to data model specifications.  I read section 3 as
    >> saying the info model talked about what data models and
    >> implementations must do, but not what administrators must use.

    Leif> OK I think we need to clean up the terminology :-)

    Leif> By implementation I think I mean what you mean by data-model
    Leif> - as in "implementation of this specification, i.e a
    Leif> data-model relative to this information model".

By implementation I mean an implementation of Kerberos.
If we add text to section 3 that says that this information model does not state whether a Kerberos implementation implementing a data model is required to implement a particular attribute: any such requirements will come from the data model.

    Leif> Section 3 talks states that this specification only talks
    Leif> about data-models relative to this information-model and
    Leif> nothing else.

Right.
I believe that is insufficient.

    >> 
    >> I'd also be happy taking Nico's approach and actually adding
    >> that here.

    Leif> As in adding language to the attribute definitions stating
    Leif> weather they MUST/SHOULD/MAY be OPTIONAL or MANDATORY in
    Leif> data-models?

No.  Whether a data model must implement an attribute is already
covered.  Discuss whether a kerberos implementation must implement an
attribute.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Tue, 27 Oct 2009 09:19:14 +0100

> covered.  Discuss whether a kerberos implementation must implement an

Ah! I understand (finally). However I'm not sure I agree that there
is a difference between the statements

"All Kerberos implementations MUST implement attribute X"

and

"In all data-models implementing the information-model
attribute X is MANDATORY".

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Oct 2009 10:16:11 -0400

>> 
    >> No.  Whether a data model must implement an attribute is
    >> already covered.  Discuss whether a kerberos implementation
    >> must implement an attribute.

    Leif> Ah! I understand (finally). However I'm not sure I agree
    Leif> that there is a difference between the statements

    Leif> "All Kerberos implementations MUST implement attribute X"

    Leif> and

    Leif> "In all data-models implementing the information-model
    Leif> attribute X is MANDATORY".

These statements are different.  One is a statement about what the
IETF must do in future documents.  One is a statement about what
implementations must do in their code.

I'm thoroughly confused at this point; you've said several things
which to me appear inconsistent.  At this point I have high confidence
that our thinking about requirement levels is muddled and that we're
not ready to send this document forward until we resolve that.

My current set of open issues can be summarized as:

* We need to clearly understand our requirement levels and why we believe they are reasonable
* If we are going to make KDCs with read-only databases (thus KDCs that do not implement failed authentication counts and the like) non-conforming, we should have a good reason.
* Once we understand the requirements issue enough to have an informed consensus about it, the text needs to reflect that.

Then separately:

* The enctypes principal attribute is still under specified.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Tue, 27 Oct 2009 16:24:28 +0100

> implementations must do in their code.

Well yes but presumably a data-model document (for instance an LDAP
schema) published as an RFC would constrain implementations of Kerberos.

Having said that - I'm all for *not* constraining Kerberos
implementations with either the data or information model but
I still claim that the two statements above are for all
intents and purposes equivalent.

> * Once we understand the requirements issue enough to have an informed consensus about it, the text needs to reflect that.

OK it seems we need more bandwidth for this. Will there be enough people
in Hiroshima to talk about requirements language at the krb-wg session?

> * The enctypes principal attribute is still under specified.

Can you elaborate (or have you already done so and I've missed it?)

	Cheers Leif

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Oct 2009 11:55:10 -0400

> in Hiroshima to talk about requirements language at the krb-wg session?

That's a good question.  So far, despite multiple requests for people to 
tell me whether they'll be in Hiroshima, I've received almost no responses. 
The data so far:

Sam - yes
Tom - yes
Me - no
Larry - no
Love - no

Similarly, despite multiple calls, I believe I've received only one request 
for agenda time (from Sam, to discuss FAST negotiation).  I know of a 
couple of other things that might want time, but I don't believe I've 
actually received any requests yet.

If this is all the data I have to go on at noon tomorrow, I will cancel the 
session.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Oct 2009 10:54:37 -0500

> intents and purposes equivalent.

One of them must constrain Kerberos implementations that are intended to
be compliant with the information model.  And someday we may want to
update RFC4120 to require that implementations conform to the
information model.

There's no point to having a document here that imposes no requirements.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Oct 2009 12:24:06 -0400

Leif> Sam Hartman wrote:
    >> >> No.  Whether a data model must implement an attribute is >>
    >> already covered.  Discuss whether a kerberos implementation >>
    Leif> and
    >> 
    >> These statements are different.  One is a statement about what
    >> the IETF must do in future documents.  One is a statement about
    >> what implementations must do in their code.
    >> 

Well yes but presumably a data-model document (for instance an LDAP
    Leif> schema) published as an RFC would constrain implementations
    Leif> of Kerberos.

Yes.  But how much is very much an open question.  Take a look at all
the complexity surrounding conformance levels/clauses for SNMP.  In
the SNMP world, all your section 3 does is say that MIB objects must
be specified for every mandatory attribute.  It doesn't say about
whether any conformance clause (I think that's the right term)
includes these objects.

I don't think LDAP has something similar.  Object classes definitely
are not: they talk about what a given directory must contain, not what
the consumers of information from a directory must or must not do with
that information.
I'm quite certain these statements are different.

Now, we could choose to say that all the items in the data model are
mandatory to implement.  That may even be the right choice.  However
when we're arguing about whether that even is a separate choice,
there's no way we can possibly claim to have informed consensus on the
result of that choice.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Tue, 27 Oct 2009 13:27:29 -0700

> attribute X is MANDATORY".

I tend to agree with Leif. I think the quoted language here only says that a 
given data model must define an element corresponding to each attribute of the 
information model. It doesn't say anything about whether these elements are 
mandatory within the context of that data model, nor do I believe it can. A 
given data model may not even have the notion of mandatory/optional attributes 
(e.g., columns in an SQL database, or key/value pairs in a simple database).
-- 
   -- 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
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Tue, 27 Oct 2009 13:56:05 -0700

Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sam Hartman wrote:
>> Then separately:
>>

The doc just says

6.1.1.13.  principalAllowedEnctype

    This optional multi valued attribute lists the enctypes allowed for
    this principal.

There is an implied reference to a data item containing a superset list of 
enctypes, but no such data item is defined.

Likewise:

6.3.1.1.  keyEncryptionType

    The enctype SHOULD be represented as an enumeration of the enctypes
    supported by the KDC.

This is somewhat ambiguous - given the other attributes in this section, it 
looks like keyEncryptionType is supposed to be a single value, but "an 
enumeration of the enctypes supported by the KDC" sounds like it should be a 
list of all the supported values.

This ambiguity needs to be removed, and there needs to be an explicit 
supportedEncTypes attribute. The description of principalAllowedEnctype should 
state explicitly that principalAllowedEncType's values are a subset of the 
values of the supportedEncTypes attribute, and likewise keyEncryptionType's 
description should state that it is a single value selected from the values of 
the supportedEncTypes attribute.

The MIT LDAP schema comments that their allowed enctypes are defined in 
RFC3961. I've added the same description and reference to the next revision of 
my LDAP schema draft. Probably the same reference should be incorporated here. 
(The current LDAP draft is being worked on here:

http://www.openldap.org/devel/cvsweb.cgi/doc/drafts/draft-chu-ldap-kdc-schema-xx.xml 
)

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Oct 2009 16:56:13 -0400

>>>>> "Howard" == Howard Chu <[email-masked]> writes:

    Howard> I tend to agree with Leif. I think the quoted language
    Howard> here only says that a given data model must define an
    Howard> element corresponding to each attribute of the information
7    Howard> model. It doesn't say anything about whether these
    Howard> elements are mandatory within the context of that data
    Howard> model, nor do I believe it can. A given data model may not
    Howard> even have the notion of mandatory/optional attributes
    Howard> (e.g., columns in an SQL database, or key/value pairs in a
    Howard> simple database).  -- -- Howard Chu CTO, Symas Corp.

1) I don't think you are agreeing with Leif: I think you are saying things that do not agree with each other.

2) You are not speaking to the issue I'm speaking about.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 27 Oct 2009 14:01:00 -0700

> 6.1.1.13.  principalAllowedEnctype

For pa-types that doesn't have explicit enctypes, this possibly an important field.

The question is what the semantics are supposed to be.

Consider the use case where a user uses PKINIT, but have no password or assigned keys.

Love

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Oct 2009 17:32:22 -0400

>>>>> "Howard" == Howard Chu <[email-masked]> writes:

    Howard> This ambiguity needs to be removed, and there needs to be
    Howard> an explicit supportedEncTypes attribute. 

Why does there need to be an explicit supported enctypes attribute?
What are its semantics?
Why is it related to 6.1.1.13

    Howard> The description
    Howard> of principalAllowedEnctype should state explicitly that
    Howard> principalAllowedEncType's values are a subset of the
    Howard> values of the supportedEncTypes attribute, 

I can't evaluate whether this is true until I know what that attribute is used for.

    Howard> and likewise
    Howard> keyEncryptionType's description should state that it is a
    Howard> single value selected from the values of the
    Howard> supportedEncTypes attribute.

If the supported enctypes attribute you're proposing is anything like
the supported enctypes configuration parameter for MIT Kerberos, this
is definitely false.  You can have a principal with a key encryption
type that is not in the supported enctypes for the KDC with MIT
Kerberos.  The MIT supported enctypes configuration parameter is
simply the set of enctypes assigned to newly keyed principals.
Principals can have additional enctypes by special administrative
action or through old keys.

---

From: Howard Chu <[email-masked]>
Date: Tue, 27 Oct 2009 14:43:59 -0700

Sam Hartman wrote:
>>>>>> "Howard" == Howard Chu<[email-masked]>  writes:
>

The current language talks about an enumeration of enctypes. There should be a 
reference to what this enumeration encompasses, e.g. RFC3961.
> action or through old keys.

No. You're talking about the MIT krbDefaultEncSaltTypes attribute.

---

From: Simo Sorce <[email-masked]>
Date: Tue, 27 Oct 2009 21:50:24 +0000

> enctypes, but no such data item is defined.

Another thing that is not mentioned is whether values should be ordered
in some specific way and if order has a meaning for the KDC.

> list of all the supported values.

No, I think it means it is one single value from a specific list,
therefore an enum type and not a free form attribute.

It doesn't specify that this should be a single valued attributed, but
probably should.

> the supportedEncTypes attribute.

Agree for principalAllowedEncType.

Not so much for keyEncryptionType, as you may have old keys in there
that has been encoded using a specific encryption type, that has been
deprecated only later and support has stopped (think of DES keys when
finally DES will not be supported anymore).
Although it is debatable whether it make sense to keep such a key.

The Information Model description of 6.3.1.1 currently supports your
statement though, when it says that it is an enumeration of types
*supported* by the KDC.

Finally, should the information model define what is the convention to
define encryption types ?

Simo.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 27 Oct 2009 15:35:14 -0700

> That principalNotUsedAfter wins?  Sure.

Don't current implementations use min({principal,password}end-time)  
when end-dating tickets?  Are we trying to specify something different?
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 27 Oct 2009 15:50:34 -0700

On Oct 27, 2009, at 1:19 AM, Leif Johansson wrote:

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkrmrQIACgkQ8Jx8FtbMZnfyvACgnliPbSyMJ6OuxkUpWDmIVRn/
> uU4An2a9l2jYBiK/TzMvxr7qQGZsHb3L
> =QEcz
> -----END PGP SIGNATURE-----

As a practical matter I think there should be a distinction.

I agree with postponing PKINIT and OTP model details.  As such the  
password-derived keys MUST be implemented in this version of the  
model.  However those attributes should be *optional* in the LDAP  
objectclass because we anticipate databases for KDC's which do not  
support passwords.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Simo Sorce <[email-masked]>
Date: Wed, 28 Oct 2009 00:14:40 +0000

> objectclass because we anticipate databases for KDC's which do not  

In current LDAP schemas most attributes are optional.
If I recall correctly, in the current schema used by MIT the only
attribute that is not optional is krbPrincipalName

In the current draft to standardize the schema the only attributes
marked as mandatory are krbPrincipalName for the krbPrincipal
objectclass and krbRealmName for the krbRealm objectclass.

Simo.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Oct 2009 19:22:19 -0500

> objectclass and krbRealmName for the krbRealm objectclass.

We're talking about "required to implement", which is very different
from "principal objects are required to have this attribute".

I think most attributes should be required to implement.  Very few
attributes, if any besides krbPrincipalName, should be required to be
present in principal objects.

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 27 Oct 2009 18:12:47 -0700

> present in principal objects.

I think what you're saying is:

If the info model says it's required, then all back-end data models  
MUST at least have a slot for the item, and an implementation MUST do- 
the-right-thing with any data that's there.  It's NOT required that  
all deployments actually fill in all "required" slots.

Agree.  Do we need some clarification of behavior when a slot is empty/ 
missing anywhere?

---

From: Tom Yu <[email-masked]>
Date: Tue, 27 Oct 2009 21:25:11 -0400

> If this is all the data I have to go on at noon tomorrow, I will cancel the 

Do we think it would be productive to discuss the information model?
I think it would be useful, assuming that enough of the participants
on the mailing list show up, or are willing to participate remotely.

I am willing to chair the session in the absence of the actual WG
chairs.  (I suspect it will also fall to me to bring the extra
computer for the Jabber projection screen if I show up.)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Wed, 28 Oct 2009 10:49:43 +0100

> There's no point to having a document here that imposes no requirements.

I note that most LDAP schemas in the IETF are informational though...
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Wed, 28 Oct 2009 10:53:35 +0100

> attribute that is not optional is krbPrincipalName

Exactly and as such they do not in practice constrain Kerberos
implementations.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Wed, 28 Oct 2009 10:57:47 +0100

> computer for the Jabber projection screen if I show up.)

I would certainly show up (since I plan to be in Hiroshima anyway) :)
but it does depend on remote participation from at least (I think)
Howard and anyone else with an interest in data-models derived from
the information model...

I think we need Sam there so him and me can figure out what (if any) the
impedance mismatch is ... :-)

	Cheers Leif

---

From: Howard Chu <[email-masked]>
Date: Wed, 28 Oct 2009 03:42:32 -0700

> impedance mismatch is ... :-)

It wasn't on my travel plans but I will certainly participate in any online 
chat or VOIP session.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Oct 2009 09:49:50 -0400

Jeff, I suggest that you summarize the current info model discussion.
I feel like I'm not really being understood and I don't seem to be
successful in explaining what I'm saying, so if you get it, I think a
summary would help a lot.

I will be at the session, and will be happy to discuss this.

It's really unfortunate that we can't get a voip audio bridge into the
room audio.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Oct 2009 10:17:30 -0500

> all deployments actually fill in all "required" slots.

The information model must say what attributes implementations must
support the use of.  The information model may also require that certain
attributes always be present.  The data models (LDAP schema, ...) may
separate add requirements on top of those of the information model.
Required implementation support vs. required presence must be
distinguished.  In all cases, the fact that an attribute is described as
required to implement does not mean that it must be present in actual
deployments; presence requirements must be stated explicitly and
separately from implementation requirements.

Thus, for the description of some attribute X, the information model
should say:

   X is REQUIRED/RECOMMENDED/OPTIONAL to implement.  [If X is REQUIRED
   to implement] Use of X is REQUIRED/OPTIONAL.

While a specific schema could say:

   X is REQUIRED/RECOMMENDED/OPTIONAL to implement, in accordance with
   the information model.  X is MUST/MAY in the actual schema.

Yes.

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 28 Oct 2009 10:33:06 -0700

'K

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Oct 2009 13:34:25 -0500

Any supported enc types attribute is, in my view, about password/key
change.  Sun an attribute needs to be discussed in the context of
password/key change protocols.

But even then, IMO we don't need this attribute at all: the password
change server should always create keys for all enctypes it supports!
What enctypes can be used for pre-auth and reply keys should be
constrained by attributes that apply to the AS exchanges.

That said, if we had consensus to require a supported enc types
attribute, we'd need to know who generates keys given a password: the
password change client, or the server?  IMO it has to be the server.  We
also need to know whether the client can or must specify what enctypes
to create keys for when setting a password.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Oct 2009 13:40:09 -0500

> * The enctypes principal attribute is still under specified.

I agree fully.

---

From: Simo Sorce <[email-masked]>
Date: Wed, 28 Oct 2009 15:02:36 -0400

> constrained by attributes that apply to the AS exchanges.

well given the information model requires you to use an enum to identify
the encryption type needed then you need information about where to find
the association between said enum and the relative encryption type.

It doesn't strictly need to be an attribute, but it would be useful for
any implementation to be able to know what data they are treating.

> password change client, or the server?

Why would that be necessary ?

> IMO it has to be the server.  We

This seem to be out of the scope.
It seem to me that an information model defines what data to store, not
how to store or use it.

Simo.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Oct 2009 14:55:29 -0500

> the association between said enum and the relative encryption type.

If the information model needs to refer to enctypes, it should do so via
RFC4120 and the enctype registry (which, IIRC is Tom Yu).

> any implementation to be able to know what data they are treating.

I don't understand this comment at all.  A password set/change server
will surely know what enctypes the KDC supports, IF it is tightly
integrated with the KDC.  Even in a realm heterogeneous KDCs they had
better all be constrained to a common set of enctypes, and the password
set/change server should use the set of enctypes it supports.  So we
still don't need this attribute.  An the answer to "it would be useful
for any implementation to be able to know what data they are treating"
is that the keys in the directory had better include entype identifiers.

> Why would that be necessary ?

It's important that users deterministically get keys for a set of
enctypes usable across all of the clients that they use.  Just because
you use say, a mobile phone to change your password doesn't mean that
you shouldn't be able to use an a enctype unsupported by that phone but
supported by another mobile device.  The only way to do this is to say
that password change servers must generate the keys.  Therefore it's
critical that the information model cover this matter.

> It seem to me that an information model defines what data to store, not

Not unless choices made in information model could impact protocols such
as password/key set/change protocols.  In this particular case the
addition of a "supported enctypes" attribute would not have a negative
impact on such protocols, but it might lead someone to create such a
protocol where the client generates the keys, which can then cause
problems (see above).  Therefore the issue of where password-derived
keys are first derived is relevant, even if tangential.

In any case, we seem to agree that a supported enctypes attribute is not
needed.

Nico

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 28 Oct 2009 13:36:58 -0700

28 okt 2009 kl. 11:34 skrev Nicolas Williams:

> But even then, IMO we don't need this attribute at all:

You need this attribute for non password/key based protocols, like PK-INIT.

Love

---

From: Tom Yu <[email-masked]>
Date: Wed, 28 Oct 2009 16:37:44 -0400

> RFC4120 and the enctype registry (which, IIRC is Tom Yu).

Enctype registrations are now administered by IANA, per RFC 3961.

http://iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tom Yu <[email-masked]>
Date: Wed, 28 Oct 2009 16:47:51 -0400

> password/key change protocols.

I think this view is (IMHO) the result of a certain configuration
variable being (somewhat inaccurately) named "supported_enctypes";
this configuration variable, in some implementations, establishes the
default set of enctypes that kadmind uses to generate a new key.  It
might be better named something like "key_generation_enctypes", but
that's not quite right either, as it isn't specific to long-term
symmetric keys.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Oct 2009 15:41:06 -0500

> You need this attribute for non password/key based protocols, like PK-INIT.

We definitely need some alloweed enctypes attributes:

a) what enctypes the AS will accept for various pre-auth methods
   (specifically PA-ENC-TIMESTAMP);

b) what enctypes the TGS will accept for PA-TGS-REQ;

c) what session key enctypes the KDC is willing to use in tickets it
   issues;

d) what enctypes the KDC is willing to use when encrypting tickets.

Clearly these are a sort of "supported enctypes" attribute.  But I think
we've been talking about an attribute like the one used by MIT krb5's
kadmind, which is rather different and means:

e) what enctypes the kadmin server will create keys for in the case that
   the client did not specify a list of enctypes when changing/setting a
   principal's password.

I believe we need (a), (b), (c) and (c), and that at least (b) and (c)
can be a single attribute.  I believe we do not need (e).  (e) is a
result of the design and history of the MIT krb5 kadmin protocol.

Perhaps there's something about Heimdal that argues for something like
(e), or perhaps there's some other enctypes argument I've missed?

Nico

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Oct 2009 17:22:53 -0400

You also need the set of enctypes that the KDC will use without preauth.

You also need the per service set of enctypes supported by the service.

However I think going the route of configuring each of these
individually is too much.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Oct 2009 16:22:58 -0500

Yes.

> You also need the per service set of enctypes supported by the service.

This one can be implied by the key set of that service principal,
however I agree that an explicit attribute would be very welcomed.

> individually is too much.

I agree.  Some of these can be combined into one.

It's the "supported_enctypes" parameter that MIT krb5 kadmind has that
is objectionable, IMO.

Nico

---

From: Simo Sorce <[email-masked]>
Date: Wed, 28 Oct 2009 18:05:34 -0400

> kadmind, which is rather different and means:

To be honest I didn't read it as what MIT kadmin calls
"supported_enctype", now I understand the confusion.

However all these lists seem to me would be better called "allowed
enctypes", as it seem you imply you limit the enctypes you can use to a
subset of the enctype you know (and perhaps support, as in: you have
code to handle them)

>    the client did not specify a list of enctypes when changing/setting a

This sound like a "default enctypes" kind of parameter ...

> I believe we need (a), (b), (c) and (c), and that at least (b) and (c)

you mean (d) here -------------------^^^ ?

> result of the design and history of the MIT krb5 kadmin protocol.

So you don't need to specify what enctypes "the server" should use to
generate the keys ?

Given this server is not the KDC, and is not necessarily MIT kadmin, it
seem to me that it may be useful to allow someone to build a different
password change server that can interoperate with the KDC without having
to rely on guesswork to know what keys needs to be generated.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Wed, 28 Oct 2009 18:06:53 -0400

> individually is too much.

Defaults should be set globally, and overrides may be set per principal
when necessary ?

Simo.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Oct 2009 17:14:04 -0500

> "supported_enctype", now I understand the confusion.

Right.  Someone earlier explained about suppoert_enctypes, and I went
from there assuming we'd all understand that that's what was meant.
Sorry!

> This sound like a "default enctypes" kind of parameter ...

That's exactly what it is.

Yes.

> to rely on guesswork to know what keys needs to be generated.

It should generate keys for all the enctypes that it knows.  The KDC
will ignore the ones it doesn't want.  There is a security consideration
here in that if you obtain the raw keys then it will be easier to mount
off-line dictionary attacks against keys of weaker enctypes, so the
server should intersect its enctype list with some "forbidden" enctype
list from the realm.  (Though if your KDB is compromied you have bigger
problems, of course.)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Wed, 28 Oct 2009 18:56:54 -0400

> list from the realm.  (Though if your KDB is compromied you have

Make sense,
so it appears that rather than a list of default/supported enctypes,
what we need is just a list of "forbidden enctypes" :-)

Simo.

---

From: Howard Chu <[email-masked]>
Date: Wed, 28 Oct 2009 16:05:45 -0700

> what we need is just a list of "forbidden enctypes" :-)

Just to establish context, the current MIT/Novell schema defines both 
krb5SupportedEncSaltTypes and krb5DefaultEncSaltTypes. On a first read-thru it 
appears that the krb5SupportedEncSaltTypes attribute is superfluous - the KDC 
already knows what enctypes it supports. I don't know the history or rationale 
behind defining this attribute in the schema; I would guess it might be useful 
for advertising to other services (such as a password change server) what 
enctypes the KDC knows about. Clearly, in an information model designed solely 
to express what a KDC needs for its own operation, this attribute is unnecessary.

Assuming the "forbidden enctypes" suggestion was more than just a joke, 
obviously it's a bad idea. Any "default allow / explicit deny" system is a 
liability.

---

From: Simo Sorce <[email-masked]>
Date: Wed, 28 Oct 2009 19:23:27 -0400

> obviously it's a bad idea. Any "default allow / explicit deny" system

It really depends on the context, in something like Access Control
evaluation I totally agree with you, in other contexts less so.

In this case setting a positive list instead of a negative one is also a
liability, because you would prevent the password change server to use
newer, better encryption types on upgrade unless you explicitly change
the configuration.

It seem to me that allowing someone to define both absolute and relative
lists would be the best compromise, and please the security paranoia of
everybody whatever form it takes :-)

IIRC this is also what the MIT code now allows using the +/- operators
on some options.

Simo.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 28 Oct 2009 17:15:17 -0700

> You need this attribute for non password/key based protocols, like  

While I agree with you, I believe the intent is to only address  
traditional random or hashed-password keys.  We should then update  
this model once we have sufficient deployment experience with PKINIT  
(and other?) pre-auth mechanisms to know how to specify their  
information.

I wonder though:  shouldn't we *at*least* have an attribute for  
allowed PA mechanisms?  Then we can specify which values (e.g.  
timestamp) this version of the info model covers.  Then we also have a  
defined way to extend the model.

I'm getting ahead of current implementations here since (at least  
Heimdal) doesn't have a general way to indicate different allowed PA  
types for different principals.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Oct 2009 10:00:18 -0400

>> individually is too much.

    Simo> Defaults should be set globally, and overrides may be set
    Simo> per principal when necessary ?

I think even that may be too much.  I believe that Nico and my list
are the complete set of things a non-FAST KDC needs to be able to
derive.

I'm not yet convinced that this information model needs more than a
better description of its one existing attribute.

We need to balance usability against power.I hope at this point that
my problem is clear: there are 8 possible things the existing
attribute could mean.  The current text does not make it clear which
one it is.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Oct 2009 10:06:53 -0400

>>>>> "Howard" == Howard Chu <[email-masked]> writes:

    Howard> Assuming the "forbidden enctypes" suggestion was more than
    Howard> just a joke, obviously it's a bad idea. Any "default allow
    Howard> / explicit deny" system is a liability.

I generally disagree with this rule for Kerberos enctypes.  In order
to deploy new algorithms you want most components in the system to
accept any reasonable enctype.  You want one component in the entire
realm to enforce some sort of policy.

As an administrator, the only place where I want to explicitly
enumerate a set of enctypes is in the set of enctypes created by
default for new principals/password changes.  I also may have a set of
enctypes that are weak enough I want to explicitly forbid them.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Oct 2009 11:02:01 -0500

>     Howard> / explicit deny" system is a liability.

Howard: this particular attribute would have no visible impact outside
the KDB itself, which has its own access controls (including encryption
of its contents or parts thereof), this would not be an access control.

> enctypes that are weak enough I want to explicitly forbid them.

Sam, I don't quite agree.  As an administrator I'd like to be able to
set policy for which entypes the KDC will access in pre-auth (including
PA-TGS-REQ) and which enctypes the KDC will accept for Ticket session
keys and Ticket encryption keys.  I'd be happy to do so via explicit
lists or via lists constructed from rules ("no weak enctypes", "only AES
enctypes", ...).

Nico

---

From: Leif Johansson <[email-masked]>
Date: Fri, 30 Oct 2009 09:40:00 +0100

> I believe that is insufficient.

While brushing my teeth today the penny dropped. You are talking about
the requirements on Kerberos implementations independent of data-models
for instance if a certain attribute MUST be read/write as opposed to
only readable. This could go into a separate doc but that seems stupid.

Clearly we need language in the information model *and* language in
section 3 for this. I'll take a stab before Hiroshima so we can get this
wrapped up.

	Cheers Leif