IETF Logo Mail Archive

Re: [kitten] CAMMAC open issues

Greg Hudson <ghudson@MIT.EDU> Mon, 11 November 2013 22:46 UTC

Return-Path: <ghudson@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 5BAE421E809D for <kitten@ietfa.amsl.com>; Mon, 11 Nov 2013 14:46:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level:
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 LHIbeuIVFM06 for <kitten@ietfa.amsl.com>; Mon, 11 Nov 2013 14:46:23 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 84A6621E8092 for <kitten@ietf.org>; Mon, 11 Nov 2013 14:46:22 -0800 (PST)
X-AuditID: 1209190e-b7efb6d000000bb9-a1-52815e3d2df2
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id F0.FA.03001.D3E51825; Mon, 11 Nov 2013 17:46:21 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id rABMkKvn008584; Mon, 11 Nov 2013 17:46:21 -0500
Received: from [18.101.8.171] (vpn-18-101-8-171.mit.edu [18.101.8.171]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rABMkFPg022486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Nov 2013 17:46:19 -0500
Message-ID: <52815E37.9020109@mit.edu>
Date: Mon, 11 Nov 2013 17:46:15 -0500
From: Greg Hudson <ghudson@MIT.EDU>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Jeffrey Hutzelman <jhutz@cmu.edu>, kitten@ietf.org
References: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu> <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu>
In-Reply-To: <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixG6nomsb1xhksH6tgcX19+fYLY5uXsXi wOSxv/UYq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJ6dl9gK1jMWXFlyxy2Bsbj7F2MnBwSAiYS rT3tTBC2mMSFe+vZuhi5OIQEZjNJdHz7zwzhbGSUWHH7GzuEc4RJYvGCPawgLbwCahIPtu0C G8UioCpx6MIeNhCbTUBZ4uDZbywgtqhAkMTxrROYIOoFJU7OfAIWFxEwk/i1+CEziC0soCGx 6e0BqNUdjBLPFt8HW8ApYCuxpeMAC8R9khLbFh0DW8YsoCPxru8BM4QtL7H97RzmCYyCs5Ds mIWkbBaSsgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfVyM0v0UlNKNzGCgphTkm8H49eD SocYBTgYlXh4d3A1BgmxJpYVV+YeYpTkYFIS5Z0TBRTiS8pPqcxILM6ILyrNSS0+xCjBwawk wvvWAyjHm5JYWZValA+TkuZgURLnvclhHyQkkJ5YkpqdmlqQWgSTleHgUJLgvRgD1ChYlJqe WpGWmVOCkGbi4AQZzgM0/DlIDW9xQWJucWY6RP4Uo6KUOK8TSEIAJJFRmgfXC0syrxjFgV4R 5t0MUsUDTFBw3a+ABjMBDXZ4VQsyuCQRISXVwJgtrLG8QLd6k285//bjeatXue3+fMpCOaRj /elPYVU97InxoUqS7E+LrP/oqZ3oPq/29IBN3xdtu/YjxQV7eqfUzE0+mBy0998S8zNz5Lly j3euNHvgqjqJI2GfcY3n/tNtKRNKsu7J3lqXnzJZ4n6Y9a0bTFfjXY+9+rZ02kKNqntlYiaJ CkosxRmJhlrMRcWJAGKIsnMNAwAA
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 22:46:46 -0000

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...".

* "Elements encapsulated with in the KDC-issued element MUST be ignored
by the application server if this 'signature' is not present."

* "This element and the elements it encapsulates MAY safely be ignored
by applications, application servers, and KDCs that do not implement
this element."

* Earlier in section 5.2.6, "If an unknown authorization data element
type is received by a server either in an AP-REQ or in a ticket
contained in an AP-REQ, then, unless it is encapsulated in a known
authorization data element amending the criticality of the elements it
contains, authentication MUST fail.  Authorization data is intended to
restrict the use of a ticket."

v2.46.0 | Report a Bug | By Email | System Status