Subject: Re: [Ietf-krb-wg] Fwd: New Version Notification for draft-ietf-krb-wg-kdc-model-05

From: Leif Johansson <[email-masked]>
Date: Thu, 6 Aug 2009 13:11:48 +0200

On Friday 31 July 2009 22.02.50 Howard Chu wrote:
> Leif Johansson wrote:
> > I think its time to last call this - I upped a new (very minor nits)
> > version since I saw that the last version was about to expire.

Thanks for reviewing this!

>
> Some notes from my LDAP Schema review....
>
> Section 6.1.1
>    Need to clarify the canonical name - I presume there should be "one and
> only one", not "one or more" canonical names. Currently the MIT schema
> allows for the latter case, which is nonsensical to me. But if that's the
> desired behavior, please state explicitly state "one or more" here.

"exactly one" is the intention I think!

>
> Section 5
>    I feel that some mention should be made in this document referring to
> existing LDAP Password Policy implementations. E.g. "This model describes a
> number of elements related to password policy management. Not all of the
> elements in this model are unique to Kerberos; an LDAP implementation of
> this model should incorporate existing LDAP schema where functional overlap
> exists, rather than defining additional Kerberos-specific elements."
>

Sounds good.

> 6.1.1.5, 6.1.1.6
>    For auditing purposes, I think that these should be consolidated into a
> single multi-valued "principalFailedAuthentications" attribute that records
> the timestamps of each failure.

That is a significant addition to the scope of the model isn't it? Storage 
requirements will increase for instance since you're essentially storing a
log inside the model. Any other opinions?

>
> Section 6.4
>    There's no discussion of policy related to ticket flags. This seems to
> be a pretty fundamental concept in KDC operation, so it's conspicuous in
> its absence.

Do you suggest we add another subsection in 6.4.2?

>
> A model attribute for the KDC realm name(s) would also seem to be
> appropriate, since the realm is also essential for KDC operation.
>

So you basically disagree with the text in 6.1.3?

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 06 Aug 2009 09:25:22 -0400

--On Thursday, August 06, 2009 01:11:48 PM +0200 Leif Johansson 
<[email-masked]> wrote:

>> 6.1.1.5, 6.1.1.6
>>    For auditing purposes, I think that these should be consolidated into
>>    a single multi-valued "principalFailedAuthentications" attribute that
>> records the timestamps of each failure.
>
> That is a significant addition to the scope of the model isn't it?
> Storage  requirements will increase for instance since you're essentially
> storing a log inside the model. Any other opinions?

I agree with Leif here -- this would be a significant change in scope, an 
requiring implementations to support it would be an undue burden.  This 
model describes things the KDC needs to operate, not data you might want to 
have when monitoring it.  The information in these two sections is needed 
in order to implement automatic lockout after a number of failed 
authentication attempts.

> Do you suggest we add another subsection in 6.4.2?

I think that's a good idea.

> So you basically disagree with the text in 6.1.3?

I don't know abot Howard, but I mostly agree with that text.  Mostly.
A KDC can provide service for multiple realms, depending on what's in its 
database; there is no such thing as "the realm".  The KDC does need to know 
for what realms it will provide service, but that sounds more like 
configuration than data to me.

-- Jeff

---

From: Howard Chu <[email-masked]>
Date: Thu, 06 Aug 2009 11:48:54 -0700

> log inside the model. Any other opinions?

True, storage requirements may go up. I would expect that only a limited 
number of failures would be recorded. However, as you say, it's definitely a 
change of scope and perhaps it should be left to a dedicated logging 
mechanism. I'll drop this point.

> Do you suggest we add another subsection in 6.4.2?

Yes, I think that would be best. Given the disconnect between the current 
Heimdal krb5KDCFlags and MIT krbTicketFlags I think it's essential that this 
be standardized. Something like

   This is a multivalued attribute containing enumerated string values 
representing the ticket flags defined in RFC4120 Section 2 "Ticket Flag Uses 
and Requests"...

> So you basically disagree with the text in 6.1.3?

Yes. While it's true that the steps in initialization of a realm are already 
covered, it's also true that principals cannot be created without a realm. 
It's OK to say that management of policies in the realm is beyond the scope of 
this document, but none of these elements - principals, keys, policies - can 
exist without first specifying a realm in which they belong.

-- 
   -- 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: Leif Johansson <[email-masked]>
Date: Thu, 6 Aug 2009 23:32:14 +0200

> >> Section 6.4
> >>     There's no discussion of policy related to ticket flags. This seems
> >> to be a pretty fundamental concept in KDC operation, so it's conspicuous
> >> in its absence.
> >
> Heimdal krb5KDCFlags and MIT krbTicketFlags I think it's essential that
> this be standardized. Something like
>
> representing the ticket flags defined in RFC4120 Section 2 "Ticket Flag
> Uses and Requests"...

You're thinking of the policy as a set of the allowed flags? A ticket flag 
policy could be a lot more complex than that. Perhaps something like 
this:

A ticket flag policy specifies the ticket flags allowed for tickets issued for
a principal. Minimally the expression of a ticket flag SHOULD be a set of 
ticket flags as defined in RFC 4120, section2.

> Yes. While it's true that the steps in initialization of a realm are
> already covered, it's also true that principals cannot be created without a
> realm. It's OK to say that management of policies in the realm is beyond
> the scope of this document, but none of these elements - principals, keys,
> policies - can exist without first specifying a realm in which they belong.

Sure but that doesn't mean the realm needs to be an element of the 
model. We could define Realm as a first order object of the model and 
have associations from the principals to each realm in which it lives but
I'm not sure what value that would add to the text... 

In other words: what property of realms other than the association of
the principal to it do you want to model?

Give me a good reason for modelling Realms and in they go :)

	Cheers Leif

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 07 Aug 2009 04:24:58 -0400

>> representing the ticket flags defined in RFC4120 Section 2 "Ticket Flag

Strings?  Why?  The ticket flags aren't strings.

> You're thinking of the policy as a set of the allowed flags? A ticket
> flag  policy could be a lot more complex than that. Perhaps something
> like  this:
>
> A ticket flag policy specifies the ticket flags allowed for tickets
> issued for a principal. Minimally the expression of a ticket flag SHOULD
> be a set of  ticket flags as defined in RFC 4120, section2.

That SHOULD is silly, since there are features which use multiple ticket 
flags that cannot be logically separated.  For example, it makes little 
sense to allow MAY-POSTDATE but not POSTDATED, or FORWARDABLE but not 
FORWARDED.

It's silly to set policy indicating whether the INITIAL, PRE-AUTHENT, 
and/or HW-AUTHENT flags may be set; the KDC should set them according to 
the actual situation (though one might want policy controlling whether any 
what preauth is required for a principal).  Similarly for 
TRANSITED-POLICY-CHECKED or OK-AS-DELEGATE.

> the principal to it do you want to model?

In other other words, despite the fact that we usually separate them in the 
protocol, how is the realm name not just part of the principal name?

---

From: Howard Chu <[email-masked]>
Date: Fri, 07 Aug 2009 03:44:58 -0700

> TRANSITED-POLICY-CHECKED or OK-AS-DELEGATE.

Right, the actual flag bits are not useful for a ticket policy. Instead you 
need a name for a feature, which may be implemented by ticket flags, or bits 
in the KRB_AS_REQ kdc_options, or some other means (like pre-auth data). Which 
is one reason to use enumerated strings here. E.g. instead of 
ALLOW-POSTDATE+POSTDATED+VALIDATE use a string "POSTDATING" to represent that 
feature.

> protocol, how is the realm name not just part of the principal name?

I guess the realm has no interesting properties of its own, other than being a 
container for the policies and principals. OK, I'll drop this point too.
-- 
   -- 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: Sat, 08 Aug 2009 11:20:43 -0700

> protocol, how is the realm name not just part of the principal name?

Hm, rethinking your question - the realm defines a namespace. Is it legal for 
a principal in a realm "user@REALM1" to have an alias based in another realm 
"alias@REALM2" ? If a realm is just an arbitrary tag for principal names, then 
I suppose it should be legal. If it's not legal, then the way that realms 
constrain naming should be defined in the data model.

---

From: Leif Johansson <[email-masked]>
Date: Sat, 8 Aug 2009 23:04:28 +0200

> TRANSITED-POLICY-CHECKED or OK-AS-DELEGATE.

So what is your suggestion - "policy may be turing complete"?

> protocol, how is the realm name not just part of the principal name?

yes

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 09 Aug 2009 00:02:48 -0400

--On Saturday, August 08, 2009 11:04:28 PM +0200 Leif Johansson 
<[email-masked]> wrote:

>> >> representing the ticket flags defined in RFC4120 Section 2 "Ticket
>> >> Flag Uses and Requests"...
>>
>> > issued for a principal. Minimally the expression of a ticket flag
>> > SHOULD be a set of  ticket flags as defined in RFC 4120, section2.
>>
>> the actual situation (though one might want policy controlling whether
>> any what preauth is required for a principal).  Similarly for

Well, it's certainly possible that any given KDC might have completely 
arbitrary policy.  But, my point is that policy is about what features you 
can use, not about what protocol elements are used to implement them. 
Ticket flags don't map 1:1 to features you might want to set policy for, 
and so a list of ticket flags is not a good abstraction for a policy object.

-- Jeff

---

From: Luke Howard <[email-masked]>
Date: Sun, 9 Aug 2009 10:33:01 +0200

On 08/08/2009, at 8:20 PM, Howard Chu wrote:

> Hm, rethinking your question - the realm defines a namespace. Is it  
> legal for a principal in a realm "user@REALM1" to have an alias  
> based in another realm "alias@REALM2" ? If a realm is just an  
> arbitrary tag for principal names, then I suppose it should be  
> legal. If it's not legal, then the way that realms constrain naming  
> should be defined in the data model.

No, it's not legal, but see draft-ietf-krb-wg-kerberos-referrals  
section 5 (enterprise principal name type).

-- Luke

---

From: Howard Chu <[email-masked]>
Date: Mon, 10 Aug 2009 04:13:15 -0700

> in order to implement automatic lockout after a number of failed

Unfortunately, the information described here is insufficient to implement a 
useful lockout mechanism. By storing only the timestamp of the last failure, 
and the total number of failures, you can't factor in the rate at which 
failures occur, and this is a key input to a lockout strategy. For example, 5 
failures in 10 seconds may constitute an attack, but 2 failures in 60 seconds 
may just be a user fumbling the keyboard. And 5 failures over a span of 
several days may just mean a user who has forgotten their password and is too 
embarrassed to ask for help yet.

If your lockout mechanism automatically unlocks after a period of time (and 
resets the counters) then attackers will be able to discover this time period 
and resume their attacks without ever tripping the limit again, and so proceed 
undetected from then on. If your mechanism doesn't reset the counters (but 
still automatically unlocks) then that means you're relying on some other 
piece of state to say "it was locked, but it's unlocked now" and that piece of 
state is missing from the model.

That's one of the reasons the LDAP policy uses the actual timestamps. Since we 
specify the maximum number of failures before lockout occurs, there's no 
danger of the storage growing without bound. There are other reasons as well, 
e.g. consistency of the policy state when replication is in use.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 10 Aug 2009 23:11:24 +0200

> can use, not about what protocol elements are used to implement them. Ticket
> flags don't map 1:1 to features you might want to set policy for, and so a
> list of ticket flags is not a good abstraction for a policy object.
>
> -- Jeff
>

Right so unless we can agree on another abstraction we might aswell stick
with the default language used in the other policy types. I don't think its
worth our time spending more time on making the expression of policy
interoperable between implementation of the information model. Policy
language tends to become, ahem *complex* and I don't think we should go
there unless we're dealing with a very simple corner case or if there is
complelling reason for interop. I don't think we have either in this case.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Aug 2009 16:58:22 -0400

Also, might you want to express cross-realm referals with aliases of a principal in a different realm?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Thu, 13 Aug 2009 14:25:16 +0200

> principal in a different realm?
Does this mean that the realm needs to be an object type in the model?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Aug 2009 09:35:40 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> On Wed, Aug 12, 2009 at 10:58 PM, Sam Hartman <[email-masked]> wrote:

    Also, might you want to express cross-realm referals with aliases of a
    Leif>     principal in a different realm?

    Leif> Does this mean that the realm needs to be an object type in
    Leif> the model?

I thought I was arguing against making the realm an object type.
But I'm not sure.
I'd ignore me;-)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Thu, 13 Aug 2009 22:16:12 +0200

> I thought I was arguing against making the realm an object type.

Then it makes more sense :-)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Wed, 19 Aug 2009 23:00:16 +0200

so did we achieve consensus that the realm name should be a property of the 
principal?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Wed, 19 Aug 2009 14:07:31 -0700

> so did we achieve consensus that the realm name should be a property of the
Looks like it. I think all the questions I raised have been addressed.