Re: [kitten] Comments on draft-ietf-krb-wg-camac-08
Simo Sorce <simo@redhat.com> Wed, 30 July 2014 11:46 UTC
Return-Path: <simo@redhat.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF281B278F for <kitten@ietfa.amsl.com>; Wed, 30 Jul 2014 04:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 rJGoplaWCGbM for <kitten@ietfa.amsl.com>; Wed, 30 Jul 2014 04:46:16 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1C91B279E for <kitten@ietf.org>; Wed, 30 Jul 2014 04:46:16 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6UBkGTh006025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 Jul 2014 07:46:16 -0400
Received: from [10.3.113.33] (ovpn-113-33.phx2.redhat.com [10.3.113.33]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6UBkBT4022466; Wed, 30 Jul 2014 07:46:12 -0400
Message-ID: <1406720770.3242.7.camel@willson.usersys.redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Date: Wed, 30 Jul 2014 07:46:10 -0400
In-Reply-To: <alpine.GSO.1.10.1407292114140.21571@multics.mit.edu>
References: <tslwqax1mhm.fsf@mit.edu> <53D7DBE2.3010105@mit.edu> <alpine.GSO.1.10.1407292114140.21571@multics.mit.edu>
Organization: Red Hat, Inc.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/UDY3pGu6dQSkbBChrm9FmERxEBc
Cc: kitten@ietf.org, Sam Hartman <hartmans-ietf@MIT.EDU>
Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 30 Jul 2014 11:46:21 -0000
On Tue, 2014-07-29 at 21:50 -0400, Benjamin Kaduk wrote: > On Tue, 29 Jul 2014, Greg Hudson wrote: > > > On 07/28/2014 12:23 PM, Sam Hartman wrote: > >> I expect advice on whether this should be contained in ad-if-relevant > >> and on how an implementation that does understand this element should > >> process contained elements that it does not understand. > > > > My preference is to: > > > > * Advise that CAMMACs be put inside AD-IF-RELEVANT. > > > > * Specify that authdata contained within a CAMMAC should be considered > > non-critical. (That is, you don't have to wrap everything inside a > > CAMMAC in AD-IF-RELEVANT.) RFC 4120 already does this for AD-KDC-ISSUED > > (section 5.2.6.2, last paragraph), presumably under the assumption that > > it is used for positive rather than negative authdata. > > It looks like we discussed the AD-IF-RELEVANT situation back in November, > but the discussion fizzled out without reaching a real conclusion. > Jeff's point in > http://www.ietf.org/mail-archive/web/kitten/current/msg04425.html that > we're designing a generic container because the previous generic container > wasn't good enough, so we should probably make sure this one is generic > enough seems pretty compelling on first re-read. On the other hand, > Greg's reply to that message is also pretty compelling, namely, that de > facto we cannot create any critical authdata and expect them to be > actually treated as critical. It would probably be good for people to > review that thread. I thought we concluded that CAMMAC does not need to be wrapped in AD-IF-RELEVANT because it has the same properties by definition and therefore is always non critical as well, but I would not mind specifying it has to be wrapped in AD-IF-RELEVANT for best compatibility. Perhaps I convinced myself we addressed the issue and then failed to make it really explicit in the text, thanks Sam for being thorough, we certainly need to add language similar to the AD-KDC-ISSUED text to make it clear. Also I do not think we need to create any specific registry with the CAMMAC specification, the intention is that the CAMMAC can contain the same AD data you would put in AD-IF-RELEVANT, just that the data is "certified" by the KDC. Simo. -- Simo Sorce * Red Hat, Inc * New York
- [kitten] Comments on draft-ietf-krb-wg-camac-08 Sam Hartman
- Re: [kitten] Comments on draft-ietf-krb-wg-camac-… Greg Hudson
- Re: [kitten] Comments on draft-ietf-krb-wg-camac-… Benjamin Kaduk
- Re: [kitten] Comments on draft-ietf-krb-wg-camac-… Simo Sorce
- Re: [kitten] Comments on draft-ietf-krb-wg-camac-… Benjamin Kaduk
- Re: [kitten] Comments on draft-ietf-krb-wg-camac-… Jeffrey Hutzelman
- Re: [kitten] Comments on draft-ietf-krb-wg-camac-… Nico Williams
- Re: [kitten] Comments on draft-ietf-krb-wg-camac-… Tom Yu
- Re: [kitten] Comments on draft-ietf-krb-wg-camac-… Nico Williams
- Re: [kitten] Comments on draft-ietf-krb-wg-camac-… Sam Hartman
- Re: [kitten] Comments on draft-ietf-krb-wg-camac-… Benjamin Kaduk
- Re: [kitten] Comments on draft-ietf-krb-wg-camac-… Nico Williams
- Re: [kitten] Comments on draft-ietf-krb-wg-camac-… Tom Yu