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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/30/2012 07:45 PM, Simo Sorce wrote:
> 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.

I don't see why. You can have additional attributes if you like and
producing a count from that audit-trail is probably easy, right?!

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

This was discussed in the WG. I don't think we should go back on that
decision wo clear consensus.

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

Same answer there. Major change at this point should come with a WG
consensus.

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

So why isn't a separate timestamp an option?

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

Do you have a suggested modification to the text?

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

Can you suggest a modified text based on my suggested re-formulation
of the time/date format requirement in the other 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 ?
> 

A valid question. I'm not 100% sure this was discussed but I'm
also uncomfortable making the change wo a clear WG consensus to
change it.

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

Again this was discussed in the WG. Please go back and review the
threads on policy.

	Cheers Leif

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/LPLsACgkQ8Jx8FtbMZneAfgCeJQlMuBlG4f7w9tPEl1Qxmoll
Rx4An3Gys1+C9JEeVAs4+1PRb5v4vzQW
=tNZF
-----END PGP SIGNATURE-----
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg