IETF Logo Mail Archive

[kitten] CAMMAC open issues

Tom Yu <tlyu@MIT.EDU> Thu, 07 November 2013 15:57 UTC

Return-Path: <tlyu@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 4B97621E809B for <kitten@ietfa.amsl.com>; Thu, 7 Nov 2013 07:57:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Xywf4i4A55S7 for <kitten@ietfa.amsl.com>; Thu, 7 Nov 2013 07:57:03 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 468BB11E810F for <kitten@ietf.org>; Thu, 7 Nov 2013 07:57:02 -0800 (PST)
X-AuditID: 1209190c-b7f058e000005fd9-65-527bb84d5aba
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id CD.ED.24537.D48BB725; Thu, 7 Nov 2013 10:57:02 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id rA7Fv14j018541 for <kitten@ietf.org>; Thu, 7 Nov 2013 10:57:01 -0500
Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id rA7FuxhP032431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <kitten@ietf.org>; Thu, 7 Nov 2013 10:57:01 -0500
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id rA7Fuxmn029108; Thu, 7 Nov 2013 10:56:59 -0500 (EST)
To: kitten@ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Thu, 07 Nov 2013 10:56:59 -0500
Message-ID: <ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu>
Lines: 26
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUixG6nruu3ozrIYOUpRoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/GdDWwFf9kqFq3za2C8xtrFyMkhIWAi0fGgixHCFpO4cG89 WxcjF4eQwGwmiekHz7CDJIQEjjFKLLxnBpF4zCSx+PwSFgink1Fi1e+zYO0iAsISu7e+Ywax hQWkJWacOAC0goODDcg+urgMJMwioCqxuGMyE4jNK2Ah8eLvQbAreAQ4JV6e3MgIEReUODnz CQuIzSygJXHj30umCYx8s5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrqJebWaKX mlK6iREUSpySPDsY3xxUOsQowMGoxMM7o6YqSIg1say4MvcQoyQHk5Io7/Ft1UFCfEn5KZUZ icUZ8UWlOanFhxglOJiVRHiPLATK8aYkVlalFuXDpKQ5WJTEeW9y2AcJCaQnlqRmp6YWpBbB ZGU4OJQkeHm2AzUKFqWmp1akZeaUIKSZODhBhvMADX8Nspi3uCAxtzgzHSJ/ilFRSpz3C0hC ACSRUZoH1wuL9VeM4kCvCPO+B6niAaYJuO5XQIOZgAaH/KoEGVySiJCSamC0n/L50uS2Wu6K Y7faX50M7tfpX3j43NprH+ccPjL71L9w3/ea06fdqD4g7fZ5u52cWttnt9ULjmo66by5l81w vsAwOSPv52b19IQdyws+bH/lN3N7/qO3b9YIC2Sa88gVG829+Hn+xqLVDppaDFHPDtr9cFC7 cbjq0xvemcJKK59o/D9kPXkDvxJLcUaioRZzUXEiACLcBuPQAgAA
Subject: [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: Thu, 07 Nov 2013 15:57:11 -0000

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.

Minor encoding change:

Do we change "other-verifiers" from "[3] SEQUENCE OF Verifier" to
"[3] SEQUENCE (SIZE (1..MAX)) OF Verifier OPTIONAL"?

I think we should do this because it would reduce the encoding size in
what I believe will be the common case of no additional verifiers.

Motivations text:

I'm still looking over Ben's suggestions for the rewording of the
"Motivations" section.

CAMMAC-BINDING:

I think I'll cover this in a separate message.

v2.23.0 | Report a Bug | By Email