Early Review of draft-ietf-krb-wg-kdc-model-
review-ietf-krb-wg-kdc-model-secdir-early-melnikov-2012-09-20-00

Request Review of draft-ietf-krb-wg-kdc-model
Requested rev. no specific revision (document currently at 16)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2012-08-28
Requested 2012-06-28
Authors Leif Johansson
Draft last updated 2012-09-20
Completed reviews Secdir Early review of -?? by Alexey Melnikov
Assignment Reviewer Alexey Melnikov 
State Completed
Review review-ietf-krb-wg-kdc-model-secdir-early-melnikov-2012-09-20
Review result Ready
Review completed: 2012-09-20

Review
review-ietf-krb-wg-kdc-model-secdir-early-melnikov-2012-09-20

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.