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

Jeffrey Hutzelman <jhutz@cmu.edu> Thu, 05 July 2012 04:17 UTC

Return-Path: <jhutz@cmu.edu>
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 E8BDF21F84C8 for <secdir@ietfa.amsl.com>; Wed, 4 Jul 2012 21:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ZR+mQr8posEH for <secdir@ietfa.amsl.com>; Wed, 4 Jul 2012 21:17:41 -0700 (PDT)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0775A21F84C5 for <secdir@ietf.org>; Wed, 4 Jul 2012 21:17:40 -0700 (PDT)
Received: from [192.168.202.99] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q654Hobd028603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2012 00:17:51 -0400 (EDT)
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Alexey Melnikov <alexey.melnikov@isode.com>
In-Reply-To: <27876_1341435865_q64L4NNL000555_4FF4AFD6.4070303@isode.com>
References: <3f40470e03a3da0a21dcf09e26f1a723.squirrel@www.trepanning.net> <27876_1341435865_q64L4NNL000555_4FF4AFD6.4070303@isode.com>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 05 Jul 2012 00:17:52 -0400
Message-ID: <1341461872.5329.22.camel@tuzanor.jhutz.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on 128.2.217.198
Cc: draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, secdir <secdir@ietf.org>, jhutz@cmu.edu
Subject: Re: [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: Thu, 05 Jul 2012 04:17:42 -0000

On Wed, 2012-07-04 at 22:04 +0100, Alexey Melnikov wrote:

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

I think the majority of your comments can be addressed by noting that
this is an abstract data model, not a schema or protocol.  So, it
discusses values that must be representable, but not what the
representation must look like, because that's up to some schema or
protocol based on this data model (e.g. an LDAP schema or XML DTD).

I thought at this point that the introduction makes this point
reasonably clear, along with the notion that "implementations" of this
documents are schemas or protocols, not pieces of software.  However, if
you didn't pick up on that, then maybe there's a better way to get it
across.


Aside from those, you also pointed three specific issues (quoted below)
which I think are answered by text in RFC3961.  If that information is
sufficient to answer your questions, then appropriate references to that
document should be inserted in the text.  Otherwise, we'll have to talk
about what the document can say to be more clear.



> In Section 4.1.1.13 - what is an enctype? :-).

See RFC3961.

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

A valid question, I suppose.  But I don't see any point in saying,
because then someone will just follow up with a question asking whether
it is allowed to be length 1.

In fact, a key held by the KDC will be a valid key for the appropriate
enctype.  The set of valid keys is a property of the enctype, as
specified in RFC3961 section 3.


> 4.3.1.3.  keySaltValue
> 
>     The binary representation of the key salt.  This MUST be a single-
>     valued octet string.
> 
> As above.

RFC3961 is quite clear that any valid UTF-8 string is permissible as a
salt.



You also pointed out several missing references; I agree with all of
those.


Leif, can you make sure we get in whatever changes are needed to address
Alexey's comments?

-- Jeff