Re: [kitten] shepherd review of draft-ietf-kitten-krb-auth-indicator-02
Nathaniel McCallum <npmccallum@redhat.com> Wed, 28 September 2016 16:53 UTC
Return-Path: <npmccallum@redhat.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D62112B621; Wed, 28 Sep 2016 09:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.217
X-Spam-Level:
X-Spam-Status: No, score=-9.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvtH_oIOjvTw; Wed, 28 Sep 2016 09:53:43 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBD112B697; Wed, 28 Sep 2016 09:50:13 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 28F0183E; Wed, 28 Sep 2016 16:50:13 +0000 (UTC)
Received: from dhcp137-207.rdu.redhat.com (dhcp137-207.rdu.redhat.com [10.13.137.207]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8SGoC9I010539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Sep 2016 12:50:12 -0400
Message-ID: <1475081412.9001.8.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Greg Hudson <ghudson@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>, draft-ietf-kitten-krb-auth-indicator@ietf.org
Date: Wed, 28 Sep 2016 12:50:12 -0400
In-Reply-To: <c0921ba3-7b3e-4716-736b-b73518dafe93@mit.edu>
References: <alpine.GSO.1.10.1609251734290.5272@multics.mit.edu> <c0921ba3-7b3e-4716-736b-b73518dafe93@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 28 Sep 2016 16:50:13 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/IOQuleEnMJrqMQBZ9svcPSZhgD0>
Cc: kitten@ietf.org
Subject: Re: [kitten] shepherd review of draft-ietf-kitten-krb-auth-indicator-02
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Sep 2016 16:53:45 -0000
I submitted a new draft with these changes. I only omitted the change to the security considerations section. We can discuss that further if need be. I stated my reasons for keeping the existing wording in another email. On Mon, 2016-09-26 at 12:28 -0400, Greg Hudson wrote: > On 09/25/2016 07:20 PM, Benjamin Kaduk wrote: > > It feels like some parts of the document are written as if the > > "short > > strings" for comparison against known values are only for use when > > presented back to the KDC, but other parts of the document describe > > it as > > being used for policy decisions made by application services as > > well as > > the KDC. > > > Application servers can use auth indicators. What parts of the > document > imply that they are only used by the KDC? > > > So, I think that section 3 should be more stringent, saying > > something like > > "strings that contain a colon character MUST be URIs that reference > > a > > Level of Assurance Profile, leaving other strings available for > > site-local use". > > > The existing text in section 3 is pretty clear to me, but if we need > to > make it more clear, I suggest replacing: > > These > strings MAY be site-defined strings that do not contain a colon > such > as the name of the Pre-Authentication mechanism used, or > alternatively URIs that reference a Level of Assurance Profile > [RFC6711]. > > with: > > Each string MUST be either: > > * A URI which references a Level of Assurance Profile [RFC6711]. > > * A site-defined string, which MUST NOT contain a colon, whose > meaning is determined by the realm administrator. > > > I also suspect that the last paragraph of the security > > considerations > > should be rewritten in a normative fashion and moved to section 3, > > to make > > it clear what the presence of a given string in the authdata > > indicates. > > (Do we know of reasons why someone might use this AD element to > > indicate > > something other than a positive indication that the indicated > > requirements > > were met during the initial authentication?) > > > That seems like a reasonable change to me. > > > There's also some matter of form regarding the string > > "AD-AUTHENTICATION-INDICATOR", which should probably just be used > > for the > > definition of the ASN.1 type; the value 97 is the ad-type for which > > the > > contents of-the ad-data field will be the DER encoding of the > > AD-AUTHENTICATION-INDICATOR object. So, I would just say "The KDC > > MAY > > include authorization data of ad-type 97, wrapped in AD-CAMMAC, > > [...]" and > > skip the line that's just > > > > AD-AUTHENTICATION-INDICATOR 97 > > > > (and replace the colon with a full stop). > > > That change also seems okay to me. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >
- [kitten] shepherd review of draft-ietf-kitten-krb… Benjamin Kaduk
- Re: [kitten] shepherd review of draft-ietf-kitten… Greg Hudson
- Re: [kitten] shepherd review of draft-ietf-kitten… Benjamin Kaduk
- Re: [kitten] shepherd review of draft-ietf-kitten… Nathaniel McCallum
- Re: [kitten] shepherd review of draft-ietf-kitten… Nathaniel McCallum
- Re: [kitten] shepherd review of draft-ietf-kitten… Benjamin Kaduk
- [kitten] intended status and Updates: 4120 for dr… Benjamin Kaduk
- Re: [kitten] intended status and Updates: 4120 fo… Greg Hudson