IETF64 Kitten WG Summary

Jeffrey Altman <jaltman@columbia.edu> Thu, 10 November 2005 19:37 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIET-0000cY-NE; Thu, 10 Nov 2005 14:37:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIER-0000cB-E2 for kitten@megatron.ietf.org; Thu, 10 Nov 2005 14:37:12 -0500
Received: from serrano.cc.columbia.edu (IDENT:cu41754@serrano.cc.columbia.edu [128.59.29.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28831 for <kitten@lists.ietf.org>; Thu, 10 Nov 2005 14:36:43 -0500 (EST)
Received: from [10.100.12.163] ([207.34.158.130]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jAAJb7TQ027118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Nov 2005 14:37:08 -0500 (EST)
Message-ID: <4373A1EC.4010703@columbia.edu>
Date: Thu, 10 Nov 2005 11:39:24 -0800
From: Jeffrey Altman <jaltman@columbia.edu>
Organization: No Longer Affiliated with Columbia University in the City of New York
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: saag@mit.edu, kitten@ietf.org, Russ Housley <housley@vigilsec.com>, Sam Hartman <hartmans-ietf@mit.edu>
X-Enigmail-Version: 0.93.0.0
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
Cc:
Subject: IETF64 Kitten WG Summary
X-BeenThere: kitten@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kitten>
List-Post: <mailto:kitten@lists.ietf.org>
List-Help: <mailto:kitten-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1532399664=="
Sender: kitten-bounces@lists.ietf.org
Errors-To: kitten-bounces@lists.ietf.org

The Kitten working group met at IETF64 on Wednesday morning.

The presentation materials are available at:
   https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64

The Audio Stream is available at

http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf64/ietf64-ch8-wed.mp3.1

The Jabber Logs are available at:

http://www.xmpp.org/ietf-logs/kitten@ietf.xmpp.org/2005-11-09.html

---------------------------------------------------------------------------------

The Kitten Working Group continued its efforts to use the IETF meeting
time for providing high-bandwidth work time to make progress on active
documents.   Unlike the Paris meeting, this room suffered from a lack
of microphones sufficient facilitate our purpose.   I propose that rooms
should provide five microphones.  One for the chair, one wireless for
the presenter, two microphones for front row participants who have read
the documents, and one floor microphone for others.

---------------------------------------------------------------------------------

Summary of document status:

* PRF API extension for GSS draft -07 submitted to IESG

* PRF API extension for GSS KRB5 mech draft -04 submitted to IESG

* C# Bindings - New draft sent to Internet-Drafts for publication
  draft-ietf-kitten-gssapi-csharp-bindings-00.txt

* Desired Enhancements to GSS Naming draft-03
  WG last call in progress ending Nov 23rd

* GSS-API Naming Extensions
  Draft -01 submitted.   Topic of technical discussion at this meeting.

* Clarifications to GSSAPI v2 Update 1
  No draft yet published.  Topic of technical discussion at this
  meeting.

--------------------------------------------------------------------------------

Technical Discussions: GSS-API Naming Extensions
draft-ietf-kitten-gssapi-naming-exts-01.txt

The working group reviewed the open issues related to this work.

Discussions were held on the merits of the gss_inquire_name_attribute()
functionality.  A preliminary decision was made to remove the
functionality from the draft as it has the potential to significantly
reduce the portability of applications.

Lengthy discussions were held on the support of negative ACLs.  The
fundamental problem with supporting negative ACLs is that in order for
them to be valid the evaluator must be able determine that the complete
set of relevant membership information is available.  This is possible
to enforce when there is only a single source of ACEs.  However, in the
model being considered, ACEs can be provided from multiple sources and
it is extremely difficult to ensure that conflicts or a failure to
provide relevant ACEs do not occur.  The WG believes there is a need to
support negative ACLs for applications such as NFSv4.  The WG proposes
supporting negative ACLs and writing appropriate Security Considerations
text describing the dangers of certain use cases.

There was much discussion of how Microsoft solved the issues in Windows
although it appears that most of the solutions are enforced by the user
interface tools preventing the construction of dangerous combinations.

It is clear that the use of "NAME" in GSS to refer to the "principal"
(the entity being authenticated) is confusing for many people.  The
documents need to be extra careful to specify the terminology.

The former CAT draft "Extended Generic Security Service APIs: XGSS-APIs
Access control and delegation extensions" was discussed as it applied to
the choice between supporting enumerated native types vs. OID tagged
blobs.  A preliminary decision was made to use OID tagged blobs.


Technical Discussions: GSS API v2 upd 1 Clarifications

The working group during the meeting wrote text for this document.
Sections include:
 - Character-set issues
 - Thread safety issues
 - Channel Bindings
   + what to do about lack of a GSS_C_AF_INET6 symbol
 - C language utilization
   + type utilization
   + name spaces
A first draft should be available real soon.

Open issue.  Are channel bindings defined on a per-mechanism basis
or are they supposed to be defined in a general manner?


_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten