Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt]

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.

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

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