--- Begin Message ---
Topics:
[Ietf-krb-wg] Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt]
Re: [Ietf-krb-wg] I-D Action: draft-ietf-krb-wg-kdc-model-12.txt
--- End Message ---
--- Begin Message ---
- To: ietf-krb-wg@xxxxxxx
- Subject: [Ietf-krb-wg] Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt]
- From: Simo Sorce <simo@xxxxxxxxxx>
- 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.
--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@xxxxxxxxxxxxx
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
--- End Message ---
--- Begin Message ---
On Wed, 2012-05-30 at 13:00 -0400, Sam Hartman wrote:
> 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.
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
--- End Message ---