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

On Sun, 2012-06-03 at 12:30 +0200, Leif Johansson wrote:
> -----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?!

Ok, I did re-read the introductory paragraph and there is space for
translation of schema models between this document and actual
implementations, so I guess this is possible.

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

Point is, I am trying to understand what that paragraph means. As is
written I can't see how to implement something that works and respects
the letter of the document, feel free to explain to me what I am reading
wrong.

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

I guess it is.

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

Not really, it seem quite difficult to substantiate this desire.

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

The text you proposed in the other mail would probably work fine.

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

ok,
Simo.

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

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