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
- [secdir] secdir review of draft-ietf-6man-lineid Dan Harkins
- [secdir] Secdir review of draft-ietf-appsawg-rece… Paul Hoffman
- Re: [secdir] secdir review of draft-ietf-6man-lin… Suresh Krishnan
- [secdir] Secdir review of draft-ietf-krb-wg-kdc-m… Alexey Melnikov
- Re: [secdir] Secdir review of draft-ietf-krb-wg-k… Jeffrey Hutzelman
- Re: [secdir] Secdir review of draft-ietf-krb-wg-k… Alexey Melnikov