[secdir] Secdir review of draft-ietf-krb-wg-kdc-model-12

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 04 July 2012 21:04 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575E821F864D for <secdir@ietfa.amsl.com>; Wed, 4 Jul 2012 14:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.894
X-Spam-Level:
X-Spam-Status: No, score=-102.894 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, 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 6YvX6jH1JiSc for <secdir@ietfa.amsl.com>; Wed, 4 Jul 2012 14:04:09 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 7C09121F85F0 for <secdir@ietf.org>; Wed, 4 Jul 2012 14:04:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1341435860; d=isode.com; s=selector; i=@isode.com; bh=xHiSHEuKDzFBYAV2EomsoI/Ecoq/t9encvHby10w+2E=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=FzN7QdmfE+kAA/Q9zYsr5ubaPl98u19t/31Ww9bnCNmU1vVxkadQpvzEVGP/72h55ubI3K TZTLGUpBtsgZYoudWKyZjzmewBMvGkQYhhZAUrxkXw+vHwjhTqOlbD8vU8Cp/1uHPsL1Ga 4Sy7kYl1xe3EmNLslrEGtbq/zQv4VzA=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <T=Sv1ABPiACL@statler.isode.com>; Wed, 4 Jul 2012 22:04:20 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4FF4AFD6.4070303@isode.com>
Date: Wed, 04 Jul 2012 22:04:22 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: draft-ietf-krb-wg-kdc-model.all@tools.ietf.org
References: <3f40470e03a3da0a21dcf09e26f1a723.squirrel@www.trepanning.net>
In-Reply-To: <3f40470e03a3da0a21dcf09e26f1a723.squirrel@www.trepanning.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: secdir <secdir@ietf.org>
Subject: [secdir] Secdir review of draft-ietf-krb-wg-kdc-model-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jul 2012 21:04:10 -0000

I have reviewed this document as part of the Security Directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the Security 
ADs. Document editors and WG chairs should treat these comments just 
like any other last call comments.

This document describes an information model for Kerberos version 5
from the point of view of an administrative service. This document
describes the services exposed by an administrative interface to a
KDC.

I believe the Security Consideration section correctly describes what 
kind of information needs protecting and how. It also talks about access 
controls and issues associated with exporting this information. I can't 
think of anything else that needs covering in the document.

I do however have a long list of nits and minor issues which I think 
need to be addressed:

In the Introduction: LDAP needs an Informative Reference.

In Section 1:

    Implementations of this document MUST be able to support default
    values for attributes as well as the ability to specify syntax for
    attribute values.

What does "the ability to specify syntax" means?


In Section 4.1.1.6 - What is the allowed range for "integer"?

In Section 4.1.1.13 - what is an enctype? :-). How do you represent one?


4.3.  Key

    Implementations of this model MUST NOT REQUIRE keys to be
    represented.

I don't know what this means.


4.3.1.2.  keyValue

    The binary representation of the key data.  This MUST be a single-
    valued octet string.


Can it be zero-length?

4.3.1.3.  keySaltValue

    The binary representation of the key salt.  This MUST be a single-
    valued octet string.

As above.


4.3.1.5.  keyNotUsedBefore

    This key MUST NOT be used before this date.  The syntax of the
    attribute MUST be semantically equivalent with the standard ISO date
    format.  This MUST be a single-valued attribute.

Is this the same format as RFC 3339? If not, why not (and what is the 
proper reference)? If yes, can you please change the definition to match 
other sections.

4.3.1.6.  keyNotUsedAfter

    This key MUST NOT be used after this date.  The syntax of the
    attribute MUST be semantically equivalent with the standard ISO date
    format.  This MUST be a single-valued attribute.

As above.

In Section 4.4.1.1: Normative References to documents defining OIDs, 
URIs (RFC 3986) and UUIDs are missing.

4.4.1.4.  policyUse

    This is an optional single enumerated string value used to describe
    the use of the policy.  Implementations SHOULD provide this attribute
    and MUST (if the attribute is implemented) describe the enumerated
    set of possible values.  The intent is that this attribute be useful
    in providing an initial context-based filtering.

I find this to be sufficiently vague to be pointless. Do you have some 
examples of what this value can be?


SOAP and Netconf (5.3/5.4) need Informative References.