last call comments on draft-ietf-krb-wg-kdc-model
Sam Hartman <hartmans-ietf@mit.edu> Wed, 30 May 2012 18:30 UTC
Return-Path: <hartmans@mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E9521F8534 for <ietf@ietfa.amsl.com>; Wed, 30 May 2012 11:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.228
X-Spam-Level:
X-Spam-Status: No, score=-103.228 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY7wj3M7Ym+V for <ietf@ietfa.amsl.com>; Wed, 30 May 2012 11:30:34 -0700 (PDT)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0252B21F8505 for <ietf@ietf.org>; Wed, 30 May 2012 11:30:33 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 76F75204BA; Wed, 30 May 2012 14:30:30 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A8E514151; Wed, 30 May 2012 14:30:31 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: ietf@ietf.org, ietf-krb-wg@anl.gov
Subject: last call comments on draft-ietf-krb-wg-kdc-model
Date: Wed, 30 May 2012 14:30:31 -0400
Message-ID: <tslr4u15xo8.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/digest; boundary="=-=-="
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 May 2012 18:30:35 -0000
--- 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 ---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@lists.anl.gov 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 ---