** IETF 64 - Vancouver, BC
** GSSAPI Next Generation (Kitten) Working Group
** Wed, Nov 9 - 09:00-11:30
Chair: Jeffrey Altman
Scribe: Love Hörnquist Åstrand
Jabber: Bob Morgan, Leif Johansson
The presentation materials are available at:
The Audio Stream is available at
The Jabber Logs are available at:
* Preliminaries - Jeffrey Altman (5 min)
- Blue Sheets
- Scribe, Jabber
- Agenda Bashing
* Document Status - Jeffrey Altman (15 min)
- Sam's Naming Draft
- PRF drafts
- C Sharp Binding
* Technical Discussions:
- GSS-API Naming Extensions (Nico Williams, Sun Microsystems) (60 min)
- Review CAT and KRB-WG mailing list archives to determine contents of
'Clarifications to GSSAPIv2' as Informational (60 min)
* Update Milestones - Chair and Participants (10 min)
* PRF API extension for GSS
- draft-ietf-kitten-gssapi-prf-07.txt submitted to IESG
* PRF API extension for GSS KRB5 mech
- draft-ietf-kitten-krb5-gssapi-prf-04.txt submitted to IESG
* C# Bindings
Juan Carlos Luciani has split the C# Bindings from the Java Bindings
into a new draft that has been submitted to Internet-Drafts for
* Desired Enhancements to GSS Naming draft
- draft-ietf-kitten-gss-naming-03.txt WG last call in progress ending
* GSS-API Naming Extensions
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===========================
Nico Williams led the working group in a review of the open issues with
* gss inquire name attributes is scary
* negatives acl entries vs paritial identity
* attribute values as tagged blobs vs native types
* concerns that naming is too hard
Discussions were held on the merits of the gss_inquire_name_attribute()
functionality. There are concerns that this function is hard to make
work correctly with names that the application does not know how to deal
with. The ability to know how to deal with a particular type can be
very environment specific. This functionality is nice but is not required.
A preliminary decision was made to remove the functionality from the draft
as it has the potential to significantly reduce the portability of
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.
* negative ACLs only work if all the information is available to
the service relying on them to make decisions
* open questions of how they should work:
- can there be a special attribute to indicate completeness?
- should we do nothing and simply wish applications that utilize
negative ACLs good luck?
- can there be mixed deny/allow orderings?
* Bill Sommerfeld feels there is "lots of doom" in this space. Partial
identities are going to be a fact of life in the GSS space. He is not
confident a workable solution can be found.
* Sam Hartman wants us to make sure that we need Negative ACLs. The WG
should produce some use cases.
* Larry Zhu provided a high level overview of how Negative ACLs are used
in the Windows Domain. Negative ACLs are safe to use in this environment
because Active Directory is able to guarrantee that all of the applicable
Universal and Domain Global Groups are present in the ACLs. The ACL
management tools will not permit the construction of negative ACLs using
groups that might not be present.
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.
Is Naming Too Hard?
Summary of the problem. GSS "NAME"s are too simple. APIs to access SAML
data would be good when SAML data exists but that won't work for X.509.
Nor would it work for the wide range of other identity (web v2) solutions
that are beginning to appear.
The Kerberos WG is examining a draft which describes an anonyomus mode for
Kerberos 5. Kitten needs to consider the implications for GSS.
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.
Technical Discussions: GSS API v2 upd 1 Clarifications====================
The working group during the meeting wrote text for this document.
- 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
* This is a clarifications document. No new definitions. We can discuss
the lack of necessary symbols but propose solutions. New definitions
should be published as a new document.
Proposed Text from Ken Raeburn:
- "pointer or arithmetic type" and ABI (no text yet, just a note)
- "const" misuse in bindings
- GSS_C_AF_INET6 (not defined, but we need it now)
- name spaces (reserved prefixes etc)
- thread safety
The use of "const" in function parameters in the GSSAPI C bindings
specification is mostly ineffective. According to the C language
specification, qualifiers like "const" on function parameters (note:
NOT values pointed to by function parameters) are essentially
meaningless. (Even if they had meaning, the only meaning would be
that a C implementation could not change the values of the arguments
(holding pointers or arithmetic values) themselves, with no impact on
the handling of any storage indicated by these handles.)
There is one case where the use of "const" is actually incorrect. The
function gss_accept_sec_context has a parameter "src_name" which is a
pointer to "const gss_name_t", yet the pointed-to storage is for an
optional output value. (This is according to the prototype in
[RFC2744] section 5.1; the sample header in Appendix A of the same
document has a different, more correct prototype.)
The intent appears to be to indicate that the referenced storage -- a
credential, a buffer, and so on -- is not modified by the GSS
function. In cases with opaque types, this can probably be assumed to
apply only to the semantic value of the underlying object, not merely
just the immediately-pointed-to storage in the cases where they are
implemented with pointers.
Ref: ISO C '99.
pointer vs arithmetic type -- even aside from varying sizes of arithmetic
types, pointers and integers can be passed differently in some platform ABIs,
so specifying "pointer or arithmetic type" is not sufficient to define an
To be fair, this is more of a registry issue. The list of address
families, their associated numeric codes, and the encoding are written
into the C bindings and used by other bindings, when they should be
language-independent. The list also predates widespread use of IPv6,
so it is not surprising that it was left out, when other values like
GSS_C_AF_CHAOS, which probably has never been used, were included.
Today, this list would probably be put in an IANA registry, with RFCs
describing the encoding of each, independent of the languange
bindings, and information in the language bindings indicating how to
transform the registered name to [...guess i stopped writing here...]
** name spaces
Aside from names starting with "gss" and "GSS", what names are likely
to be defined, declared, or used in gssapi.h? Are any names not
explicitly defined in [RFC2744] reserved for future use?
If the header file is provided by the operating system vendor, this
might qualify it as part of the C implementation, and thus names
starting with "__" may be used for any internally-used macros or
When xom.h is available on a system, it is specified that xom.h is
included by gssapi.h, so clearly any namespace used by that header (at
least "OM_*" and "OMP_*" symbols) may be defined by the inclusion of
** thread safety
The simple, safe answer is that a GSSAPI implementation need not be
thread-safe. It is likely that implementations will not be safe to
use in multiple threads simultaneously; it may well be the case that
some implementations are not safe to use from more than one thread
under any circumstances. Even if the implemenation has no internal
static storage modified by multiple threads, it may call out to other
routines (in the system libraries or elsewhere) that may not be thread
safe. Even if the application uses a mutex lock to ensure that only
one thread uses the GSSAPI routines at any one time, non-thread-safe
functions called from it may conflict with non-GSSAPI calls the
application may make in other threads.
On the other hand, some implementations have attempted to provide some
measure of thread safety. Implementors are encouraged to document
what level of thread safety they provide, and any restrictions related
to multithreaded programming. Portable applications should not use
GSSAPI in multiple threads, though multithreaded applications may be
written for specific implementations.
See also [Boehm] for a discussion of issues in attempting to discuss
thread support without making it integral to the base language
Ref: Boehm, Hans-J. "Threads Cannot Be Implemented As a Library",
conference proceedings, ACM SIGPLAN 2005 Conference on Programming
Language Design and Implementation.
Proposed Text from Nico Williams: Character Set issues.
RFC 2744 refers to Latin-1. However, the character set issues
within mechanisms expose themselves via GSS. Nico proposes
removing references to Latin-1 in the C Bindings and adding text
to the generic API specifying:
the character set used for gss_import_name(), gss_display_name(),
gss_display_status() and any other places where one is needed will
be determined by the application's/platform's locale
* Are channel bindings defined on a per-mechanism basis or are they
supposed to be defined in a general manner?
Ken Raeburn will be editor for this draft.
* remove gss_inquire_name_attribute() from
* draft-ietf-kitten-gssapi-naming-exts-01.txt will use OID tagged
blobs for ACL data
* Ken Raeburn will edit the GSS API v2 Upd 1 Clarifications draft
* Nico will publish revisions to
* Milestones were not revised at this meeting