Re: [kitten] CAMMAC open issues
Jeffrey Hutzelman <jhutz@cmu.edu> Mon, 11 November 2013 23:21 UTC
Return-Path: <jhutz@cmu.edu>
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 5C59C21E80AE for <kitten@ietfa.amsl.com>; Mon, 11 Nov 2013 15:21:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.289
X-Spam-Level:
X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 xA7nUI+nssYU for <kitten@ietfa.amsl.com>; Mon, 11 Nov 2013 15:20:59 -0800 (PST)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 6700B21E80B5 for <kitten@ietf.org>; Mon, 11 Nov 2013 15:20:59 -0800 (PST)
Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id rABNKwIS002990 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 11 Nov 2013 18:20:58 -0500 (EST)
Message-ID: <1384212058.31412.41.camel@minbar.fac.cs.cmu.edu>
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Greg Hudson <ghudson@MIT.EDU>
Date: Mon, 11 Nov 2013 18:20:58 -0500
In-Reply-To: <10051_1384210008_rABMklPw010752_52815E37.9020109@mit.edu>
References: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu> <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu> <10051_1384210008_rABMklPw010752_52815E37.9020109@mit.edu>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.3-0ubuntu6
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
X-Scanned-By: mimedefang-cmuscs on 128.2.217.198
Cc: kitten@ietf.org, jhutz@cmu.edu
Subject: Re: [kitten] CAMMAC open issues
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 11 Nov 2013 23:21:05 -0000
On Mon, 2013-11-11 at 17:46 -0500, Greg Hudson wrote: > On 11/11/2013 04:51 PM, Jeffrey Hutzelman wrote: > > I fail to see how these are alternatives. As a wrapper, AD-IF-RELEVANT > > has special semantics which nullify the criticality of the element it > > wraps. AD-KDCIssued does not have this property. > > My reading of RFC 4120 section 5.2.6.2 is that AD-KDCIssued authdata are > implicitly non-critical. The text isn't as precise as I would like, but: > > * "The KDC-issued ad-data field is intended to provide a means for... > positive authorization...". Not relevant. > * "Elements encapsulated with in the KDC-issued element MUST be ignored > by the application server if this 'signature' is not present." I'm not even sure what this means, since the 'signature' is contained in a non-optional field; if it's not present, the AD won't parse. > * "This element and the elements it encapsulates MAY safely be ignored > by applications, application servers, and KDCs that do not implement > this element." I somehow missed this. In which case, yes, wrapping in AD-KDCIssued would indeed obviate the need to wrap in AD-IF-RELEVANT. However, that means that wrapping in AD-KDCissued is not a substitute for using the svc-verifier, since the former carries semantics affecting criticality. If we drop svc-verifier, then there is no way to issue credentials containing AD that is both authenticated and critical! IMHO, we should simply note that most already-deployed services will not understand AD-CAMMAC, and specify that it SHOULD be enclosed in AD-IF-RELEVANT unless it contains authorization data which is critical with respect to the service or some principal named in other-verifiers. Probably we should also indicate that AD-CAMMAC-BINDING SHOULD be enclosed in AD-IF-RELEVANT unless the containing AD-CAMMAC is already so wrapped, and modify the text so that an AD-CAMMAC whose first element is an AD-IF-RELEVANT wrapping AD-CAMMAC-BINDING is permissible. Incidentally, it's not clear that wrapping AD-CAMMAC in AD-IF-RELEVANT automatically confers full non-criticality on all of the wrapped elements! The definition of AD-IF-RELEVANT in RFC4120 5.2.6.1 is ambiguous in this respect. It may be desirable to clarify that if a particular AD-CAMMAC is wrapped in AD-IF-RELEVANT, the non-criticality applies to all of its elements. -- Jeff
- [kitten] CAMMAC open issues Tom Yu
- Re: [kitten] CAMMAC open issues Jeffrey Hutzelman
- Re: [kitten] CAMMAC open issues Greg Hudson
- Re: [kitten] CAMMAC open issues Tom Yu
- Re: [kitten] CAMMAC open issues Jeffrey Hutzelman
- Re: [kitten] CAMMAC open issues Benjamin Kaduk
- Re: [kitten] CAMMAC open issues Jeffrey Hutzelman
- Re: [kitten] CAMMAC open issues Greg Hudson
- Re: [kitten] CAMMAC open issues Benjamin Kaduk
- Re: [kitten] CAMMAC open issues Jeffrey Hutzelman