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
>