Subject: [Ietf-krb-wg] I-D Action: draft-ietf-krb-wg-kdc-model-12.txt

From: [email-masked]
Date: Tue, 29 May 2012 04:06:32 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberos Working Group of the IETF.

	Title           : An information model for Kerberos version 5
	Author(s)       : Leif Johansson
	Filename        : draft-ietf-krb-wg-kdc-model-12.txt
	Pages           : 18
	Date            : 2012-05-29

   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kdc-model-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-krb-wg-kdc-model-12.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-krb-wg-kdc-model/

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 May 2012 13:00:07 -0400

I'd like to call the working group's attention to the new text
surrounding RFc 2119 language.  In particular in this draft, MUST
features in the information model MUST be representable in schema *and*
MUST be supported by all implementations of the information model.  That
last was intended by Leif but was new to me.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Wed, 30 May 2012 13:13:19 -0400

> last was intended by Leif but was new to me.

Thanks for bringing this up Sam.

I am reading the doc now and I have a question as to why we have a MUST
on the syntax of attributes like principalNotUsedBefore.

It says it MUST use "Internet Date/Time Format from [RFC3339]"

This is problematic as LDAP uses generalizedTime defined in RFC4517.
It is a representation of ISO8061 just like RFC3339, but a *different*
representation.

Trying to force all implementations to use the RFC3339 definition seem
wrong.
What implementation, today, uses RFC3339 ?

I would rather suggest that the document does not mandate the specific
representation discussed in RFC3339 but allow any ISO8601 based
representation.

If it is felt that one representation really needs to be chosen then I'd
ask to use the generalizedTime representation as defined by RFC4517
instead of the one in RFC3339.

Simo.

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

---

From: Simo Sorce <[email-masked]>
Date: Wed, 30 May 2012 13:45:15 -0400

I have additional comments.

These following 3 attribute definitions bind the implementer to a very
special way to address counting failed authentication attempts.

4.1.1.5.  principalNumberOfFailedAuthenticationAttempts

   This single-valued integer attribute contains a count of the number
   of times an authentication attempt was unsuccessful for this
   Principal.  Implementations SHOULD NOT allow this counter to be
   reset.

4.1.1.6.  principalLastFailedAuthentication

   This single-valued attribute contains the time and date for the last
   failed authentication attempt for this Principal.  The syntax of the
   attribute MUST be Internet Date/Time Format from [RFC3339].

4.1.1.7.  principalLastSuccessfulAuthentication

   This single-valued attribute contains the time and date for the last
   successful authentication attempt for this principal.  The syntax of
   the attribute MUST be Internet Date/Time Format from [RFC3339].\

They force a mechanism where you have a specific counter. It seems to
prevent instead an implementation that may have a multi-valued attribute
where all failed attempts are recorded in order to have an audit trail,
and the number of failed attempts is computed by counting these values.

However assuming that this scheme is really preferred, then I do not
understand how it can be implemented if 4.1.1.5 says that the counter
should not be reset. I think implementations need to reset it when a
successful authentication happens. I think that should be explicitly
said, rather than a blanket 'SHOULD NOT reset'.

I would like to make 4.1.1.8, 4.1.1.9 a SHOULD, not a MUST

The way 4.1.1.10 is worded makes it impossible to reuse the
modifyTimestamp attribute normally present in LDAP directories, as
Kerberos implementations cannot force the directory not to update the
timestamp on credential changes, so please drop the exclusion, I do not
see what's the point anyways.

In 4.2, it is unclear what 'MUST facilitate, to the extent possible, an
   administrator's ability to place more restrictive access
controls ...' will end up being interpreted.
How do you measure if an implementation complies with this mandate ?

I am not sure I understand 4.3.

4.3.1.5 and 4.3.1.6 are not consistent with the rest of the document
about how the date format is mandated. (Will need to be fixed to
whatever we decide after discussion about date format I opened in a
separate thread)

Also keyNotUsedBefore keyNotUsedAfter keyIsDisabled are not something
normally associated to key attributes today generally they are
associated to keysets, is there a MUST implied in these having to be
available per key, and not per keyset ?

I find the part on policy a bit hand-wavy, what is the point of
identifying specific, yet undefined, policies with OIDs if they are
opaque in the end ?

Simo.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 May 2012 14:29:48 -0400

[I'm going to forward Simo's original comments to the IETF list because
this doc is in IETF last call.
Here are my responses as chair.
]
>>>>> "Simo" == Simo Sorce <[email-masked]> writes:

    Simo> 4.1.1.5.  principalNumberOfFailedAuthenticationAttempts

    Simo>    This single-valued integer attribute contains a count of
    Simo> the number of times an authentication attempt was unsuccessful
    Simo> for this Principal.  Implementations SHOULD NOT allow this
    Simo> counter to be reset.

[. . .]

    Simo> They force a mechanism where you have a specific counter. It
    Simo> seems to prevent instead an implementation that may have a
    Simo> multi-valued attribute where all failed attempts are recorded
    Simo> in order to have an audit trail, and the number of failed
    Simo> attempts is computed by counting these values.

I think you'd also need to record last successful authentication.
However, given last successful authentication and  a set of failed
authentications I think it's  quite easy to give an algorithm for
producing count of failed authentications and  last failed
authentication.
It does mean that to increment the count of failed authentications you
need to decide on a time for the list of failed authentications.
I think  that's consistent with the information model though.

    Simo> However assuming that this scheme is really preferred, then I
    Simo> do not understand how it can be implemented if 4.1.1.5 says
    Simo> that the counter should not be reset. I think implementations
    Simo> need to reset it when a successful authentication happens. I
    Simo> think that should be explicitly said, rather than a blanket
    Simo> 'SHOULD NOT reset'.

There was WG discussion on this.
The text really means the count should be non-decreasing.
This  makes it impossible to implement a policy like 2 failed auths
since the last successful auth.

With my chair hat on, my reading of the discussion is that we really do
mean what the text says. However, I don't think the point about being
unable to track number of failed auths since last successful auth has
been brought up before and that point is sufficient to reopen the
discussion.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg