Re: [kitten] CAMMAC open issues
Benjamin Kaduk <kaduk@MIT.EDU> Tue, 12 November 2013 04:11 UTC
Return-Path: <kaduk@mit.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 C228511E814B for <kitten@ietfa.amsl.com>; Mon, 11 Nov 2013 20:11:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 D+hIQpIKZtam for <kitten@ietfa.amsl.com>; Mon, 11 Nov 2013 20:11:19 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2204311E81A5 for <kitten@ietf.org>; Mon, 11 Nov 2013 20:11:17 -0800 (PST)
X-AuditID: 12074424-b7fa56d000000be4-c2-5281aa64692c
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 59.93.03044.46AA1825; Mon, 11 Nov 2013 23:11:16 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id rAC4BFIA015666; Mon, 11 Nov 2013 23:11:16 -0500
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rAC4BDK2026971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Nov 2013 23:11:15 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id rAC4BDZO002003; Mon, 11 Nov 2013 23:11:13 -0500 (EST)
Date: Mon, 11 Nov 2013 23:11:13 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
In-Reply-To: <1384212058.31412.41.camel@minbar.fac.cs.cmu.edu>
Message-ID: <alpine.GSO.1.10.1311112304380.4934@multics.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> <1384212058.31412.41.camel@minbar.fac.cs.cmu.edu>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrJuyqjHI4MpMA4vr78+xWxzdvIrF gcljf+sxVo8lS34yBTBFcdmkpOZklqUW6dslcGXcv9zOVDBJpOL5tfwGxjUCXYycHBICJhLP /s1nhLDFJC7cW8/WxcjFISQwm0nizOFVrBDORkaJ16tWMkM4h5gkWr/uhXIaGCXm/jnICtLP IqAt8WPSD3YQm01ARWLmm41sILaIgKrEvTmzWLoYOTiYBYwkLvzKAAkLC2hIbHp7AKyEU8BO YtWvdhYQm1fAQeJ0Sz/UGV8ZJR70TAFLiAroSKzePwWqSFDi5MwnYDazgKXEuT/X2SYwCs5C kpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrlebmaJXmpK6SZGUKiyu6jsYGw+pHSI UYCDUYmHdwdXY5AQa2JZcWXuIUZJDiYlUV6zFUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzh i4FyvCmJlVWpRfkwKWkOFiVx3lsc9kFCAumJJanZqakFqUUwWRkODiUJ3sKVQI2CRanpqRVp mTklCGkmDk6Q4TxAw01AaniLCxJzizPTIfKnGBWlxHkzQRICIImM0jy4XlgqecUoDvSKMK8t SBUPMA3Bdb8CGswENNjhVS3I4JJEhJRUA+PqEs7Khf4Nu69E8/3XYJm1Y06K/6FpJyQl4qu+ 7Rfr/HS7eXvuptnNb41ldlznWNRyQO3TJ++pKSdC2U933b/xUX7TWiaeTXOOLiybUzXtzWXp R3dvquUaH/9VJ/+Ua714fLG78FXVicnX5xt78UivP+S/Kf+8a7wD93GxLYvCX5TnMkhKnNZU YinOSDTUYi4qTgQA96KxhgADAAA=
Cc: kitten@ietf.org
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: Tue, 12 Nov 2013 04:11:29 -0000
On Mon, 11 Nov 2013, Jeffrey Hutzelman wrote: > 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. It seems relevant in a circumstantial way, in that there is not a security risk from ignoring unknown positive authorization data in the way that there is for ignoring unknown negative authorization data. >> * "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. Do we anticipate there ever being such critical data? It seems like it would be simpler if we could specify that it is always AD-IF-RELEVANT. > 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. It's not immediately clear to me why, if the contents are just an OCTET STRING. > 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 Ugh. -Ben
- [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