Subject: IETF64 Kitten WG Summary

From: Jeffrey Altman <[email-masked]>
Date: Thu, 10 Nov 2005 11:39:24 -0800

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/[email-masked]/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
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten