Re: [kitten] CAMMAC open issues
Jeffrey Hutzelman <jhutz@cmu.edu> Mon, 11 November 2013 21:51 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 C00C811E80F9 for <kitten@ietfa.amsl.com>; Mon, 11 Nov 2013 13:51:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.134
X-Spam-Level:
X-Spam-Status: No, score=-106.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 1LtgtyBNzFrB for <kitten@ietfa.amsl.com>; Mon, 11 Nov 2013 13:51:34 -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 CAFEC11E8114 for <kitten@ietf.org>; Mon, 11 Nov 2013 13:51:33 -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 rABLpWgC000198 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 11 Nov 2013 16:51:32 -0500 (EST)
Message-ID: <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu>
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: kitten@ietf.org
Date: Mon, 11 Nov 2013 16:51:32 -0500
In-Reply-To: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu>
References: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.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: 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 21:51:39 -0000
On Thu, 2013-11-07 at 10:56 -0500, Tom Yu wrote: > Here are what I think are the remaining open issues for CAMMAC. > > Wrapping of CAMMAC: > > Do we recommend enclosing a CAMMAC inside an AD-IF-RELEVANT? RFC 4120 > says that authorization data are critical, i.e., an implementaiton > must reject unrecognized authorization data. Alternatively, we could > require that CAMMAC be enclosed in an AD-KDCIssued, and drop the > consequently redundant "svc-verifier" from CAMMAC. 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. -- 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