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

Alexey Melnikov <> Fri, 13 July 2012 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4C2F11E8097 for <>; Fri, 13 Jul 2012 11:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.039
X-Spam-Status: No, score=-103.039 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nvS2QPxqkWVY for <>; Fri, 13 Jul 2012 11:59:32 -0700 (PDT)
Received: from ( [IPv6:2a00:14f0:e000:7c::2]) by (Postfix) with ESMTP id 9DC1D21F865E for <>; Fri, 13 Jul 2012 11:59:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342206033;; s=selector;; bh=i/hiAgur7nRhId7pcAU1H29KbzpLaWRRDIs/VHiLdVs=; 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=JZUKaLPGTqFnG1/5HRdMDqkCbkfhxa6zV1NuUWtOpq0LvhOfoCjdL0D2NSKeLbR76Qct0d WrvRyMoeazZRFZFb28SwSzT6vP45hPJWs8tmZBhP6UpduzL8KggvIwDC9clZiq1O1SJkQq J6dNiaf+nBHpX9Ukq0Q1gdtkRfxjGtE=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Fri, 13 Jul 2012 20:00:32 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <>
Date: Fri, 13 Jul 2012 20:00:33 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: Jeffrey Hutzelman <>
References: <> <> <1341461872.5329.22.camel@tuzanor.jhutz.local>
In-Reply-To: <1341461872.5329.22.camel@tuzanor.jhutz.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc:, secdir <>
Subject: Re: [secdir] Secdir review of draft-ietf-krb-wg-kdc-model-12
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Jul 2012 18:59:34 -0000

On 05/07/2012 05:17, Jeffrey Hutzelman wrote:
> 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).

Not too abstract though. If you say something is an integer and one 
protocol can only support 32bit integers, while another can support 
128bit, one of them might be unusable unless your definition is more 

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

See above.

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

Having very specific references (to section numbers) is likely to solve 
issues, yes.

>> In Section - what is an enctype? :-).
> See RFC3961.
>>  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.

Ok, a reference would do.

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

Ok, good.

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