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

From: Leif Johansson <[email-masked]>
Date: Mon, 19 Oct 2009 23:38:14 +0200

I think we can WGLC this version - it contains the text representing
the consensus on including the realm as an attribute on the principal
object.

	Cheers Leif

Subject: New Version Notification for draft-ietf-krb-wg-kdc-model-06
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Date: Mon, 19 Oct 2009 14:11:39 -0700 (PDT)

A new version of I-D, draft-ietf-krb-wg-kdc-model-06.txt has been successfuly submitted by Leif Johansson and posted to the IETF repository.

Filename:	 draft-ietf-krb-wg-kdc-model
Revision:	 06
Title:		 An information model for Kerberos version 5
Creation_date:	 2009-10-19
WG ID:		 krb-wg
Number_of_pages: 18

Abstract:
This document describes an information model for Kerberos version 5
from the point of view of an administrative service.  There is no
standard for administrating a kerberos 5 KDC.  This document
describes the services exposed by an administrative interface to a
KDC.

The IETF Secretariat.

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

---

From: Howard Chu <[email-masked]>
Date: Mon, 19 Oct 2009 19:20:10 -0700

Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>

Sorry, one last question, which I kept forgetting to ask before:

Section 6.1.1.5, principalNumberOfFailedAuthenticationAttempts:

  Implementations SHOULD NOT allow this counter to be
    reset.
<<<

What's the purpose of this constraint? Is it really intended to keep a count 
of every authentication failure over the life of the principal? Or was it 
intended to only count failures since the last successful authentication? Is 
the intent just to prevent reset by individual users? Surely a KDC 
administrator should be allowed to reset it for whatever reason?

-- 
   -- 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: Tue, 20 Oct 2009 10:16:27 +0200

Howard Chu wrote:
> What's the purpose of this constraint? Is it really intended to keep a
> count of every authentication failure over the life of the principal? Or
> was it intended to only count failures since the last successful
> authentication? Is the intent just to prevent reset by individual users?
> Surely a KDC administrator should be allowed to reset it for whatever
> reason?
> 

The intent is to have a very reliable source of information for
dictionary-based attacks. If you allow reset then you can never be
sure that a broken admin user was used to erase trails of a successful
dict attack. It seems prudent...

	Cheers Leif

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Oct 2009 13:56:10 +0200 (MEST)

> administrator should be allowed to reset it for whatever reason?

What you're looking for seems to be a lockout-counter, that is
reset by successful logons, password change or adminstrator privilege.

-Martin

---

From: Howard Chu <[email-masked]>
Date: Tue, 20 Oct 2009 07:30:51 -0700

> reset by successful logons, password change or adminstrator privilege.

Right, that's what I was assuming this was, but I guess that was a mistaken 
assumption. It would probably be a good idea to state the intended use for 
this item more completely.

---

From: Simo Sorce <[email-masked]>
Date: Tue, 20 Oct 2009 15:37:19 -0400

> dict attack. It seems prudent...

Wouldn't this better identified by keeping off-server logs instead?
A single counter doesn't tell you much about when the errors occurred,
so it seem like a very vague indicator at best.

Simo.

---

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

One really trivial point, but it bothers me every time I read through this 
document: Can you please use the same order for the sections for 
principalNotUsedBefore/After and keyNotUsedBefore/After? Currently the doc has

6.1.1.2 principalNotUsedBefore
6.1.1.3 principalNotUsedAfter

6.3.1.5 keyNotUsedAfter
6.3.1.6 keyNotUsedBefore

I don't care which order you use, as long as both match. Going for lexical 
ordering, this would change:

6.1.1.2 principalNotUsedAfter
6.1.1.3 principalNotUsedBefore

Going for logical ordering (the Before requirement takes effect first) would 
change:

6.3.1.5 keyNotUsedBefore
6.3.1.6 keyNotUsedAfter