[10:52:55] --- hartmans has become available
[11:02:35] --- raeburn has become available
[11:03:29] --- nico has become available
[11:03:51] --- rlbob has become available
[11:04:05] --- tlyu has become available
[11:04:41] --- Jeffrey Altman has become available
[11:07:48] --- nov has become available
[11:08:22] --- leifj has become available
[11:08:58] --- lha has become available
[11:09:07] <rlbob> meeting starts
[11:09:18] <rlbob> document status, not recorded ...
[11:09:29] <rlbob> nico presents on naming extensions draft
[11:09:42] <rlbob> recap of proposal:
[11:09:43] <Jeffrey Altman> slide 2 from the presentation
[11:10:04] <rlbob> names as bag of attr/values
[11:11:00] <rlbob> various issues: inquire_name_attribute scary, negative acls, blobs vs types, ...
[11:11:31] <rlbob> (reading the slides from the presentation, I won't attempt to retype ...)
[11:13:41] <rlbob> now on slide 5 ...
[11:14:53] <rlbob> bill sommerfeld: getting posix semantics out of nfsv4 acls requires neg ACEs, sense of doom
[11:15:07] <rlbob> nico: not sure that partial identity is fatal in that case
[11:15:41] <rlbob> nico: other cases where it is fatal
[11:16:01] <rlbob> nico: have you communicated sense of doom to those folks?
[11:16:18] <raeburn> http://onsite.ietf.org/proceedings/05nov/slides/kitten-0.pdf has nico's slides
[11:16:26] <rlbob> bills: just have to cope with neg ACLs in some contexts, may need more complex notion of completeness
[11:17:32] <rlbob> now on slide 6
[11:17:50] <rlbob> tagged blobs vs native types
[11:18:56] <rlbob> proposal: keep blobs, add functions to convert to native types
[11:19:20] <rlbob> slide 7: naming too hard?
[11:19:23] <raeburn> (jaltman's slides: http://onsite.ietf.org/proceedings/05nov/slides/kitten-1.pdf)
[11:22:31] --- alexeymelnikov has become available
[11:23:55] <rlbob> leif: why not just standardize on SAML attributes?
[11:24:00] <rlbob> nico: could be:
[11:24:40] <rlbob> rlbob as himself: fully-attributed identity is a necessity in the modern world, many people defining in many ways
[11:25:02] <rlbob> rlbob more: SAML value repr may have some ambiguity that would need to be fixed to be fully general
[11:25:11] <rlbob> anonymity slide ...
[11:25:33] <rlbob> slide 9: mech-specific
[11:26:22] <rlbob> jeff: let's try to address issues
[11:26:35] <rlbob> nico: ok, start with gss_inquire_name_attr
[11:26:54] <rlbob> sam: expressed position at Paris IETF ...
[11:27:34] <rlbob> sam: concern is doesn't work with names you don't know about, adds complexity, apps can deal with its absence
[11:28:27] <rlbob> sam: will lead to decreased app portability
[11:29:27] <rlbob> sam: let's get experience without feature, see whether/how it's needed
[11:29:42] <rlbob> nico: probably OK
[11:30:37] <rlbob> hum: all who hum agree with leaving it out for now
[11:32:03] <rlbob> negative ACL issue
[11:32:23] <rlbob> sam: let's look at where people want them, and where problems come up
[11:33:19] <rlbob> sam: shouldn't be allowed to hide so much identity that you can be anonymous while still respecting acls ...
[11:33:44] <rlbob> sam: that is, policy that permits anonymous but denies to specified users is a problem policy
[11:34:42] <rlbob> nico: willing to talk to nfsv4 folks to see if they can live with simplicity
[11:35:33] <rlbob> larry zhu: yes, windows has neg acls, more in next version, special SIDs only for use with neg acls
[11:36:24] <rlbob> lz: suggest introducing notion of principal as better abstraction than name
[11:36:34] <rlbob> nico: how different than bag-of-attrs?
[11:37:19] <rlbob> lz: admin has harder time to understand acling vs bag-of-attrs than principal
[11:38:13] <rlbob> lz: principal is more tied to identity
[11:38:24] <rlbob> nico: in windows principal is SID
[11:38:41] <rlbob> lz: no, in win principal is NT token, not SID
[11:39:36] <rlbob> nico: gssapi has principal concept already
[11:40:00] <rlbob> nico: but principal isn't general enough
[11:40:32] <rlbob> lz: principal is security identity
[11:40:45] <rlbob> wyllys: doesn't principal have attrs?
[11:41:27] <rlbob> lz: in win principal has set of local privs ...
[11:42:11] <rlbob> nico: "name" is just the name of the type in GSS, is referring to principal concept
[11:45:31] <rlbob> bills: just a terminology thing, kerb uses "principal" term
[11:46:05] <rlbob> rlbob: easy to argue about which word is best, but words refer to model components, is there a model difference here?
[11:47:14] <rlbob> sam: gss_import_name brings in ... entity plus attributes, may involve dir lookups etc, is that enough?
[11:47:35] <rlbob> lz: doesn't seem enough (?)
[11:48:15] --- okabe has become available
[11:51:02] <rlbob> nico: (explanation of gss features) might help larry if NAME were "principal" or "identity"
[11:51:44] <rlbob> lz: that distinction isn't clear from presentation, or draft
[11:52:07] --- okabe has left
[11:52:09] <rlbob> love: NAME is confusing to me too
[11:54:42] --- beuchelt has become available
[11:54:52] <rlbob> tom yu: does seem to be term problem, what to call canonicalized thing, kerb uses "principal" for "principal name", gss uses "name"
[11:55:42] <rlbob> sam: nico and I are arguing to expand GSS NAME scope to increase from Kerb "principal" to larry's "principal"
[11:55:56] <rlbob> sam: people agree that that's what's happening? (agreement)
[11:56:33] <rlbob> jhutz: proposal is expanding GSS NAME type from identifier to description
[11:57:21] <rlbob> nico: NAME is handle, we're adding functions to permit manipulating data about this handle
[11:58:02] <rlbob> sam: so there's something to do here to clarify what's meant
[12:00:25] --- rlbob has left
[12:03:01] <leifj> nico: comment on native types
[12:04:14] <leifj> nico: sure, native applications want native representation of privs, names etc
[12:04:34] <leifj> nico: but we still need a general network representation and conversion
[12:05:00] <leifj> larry: mostly concerned with abstraction of the object not representation
[12:05:21] <leifj> nico : should we rename?
[12:05:29] <leifj> larry: not just rename - make it coherent
[12:06:08] <leifj> jeff: lets worry about wordsmithing later
[12:06:26] <leifj> jaltman: discussion is allowed!
[12:06:55] <leifj> jaltman: we are discussing negative acls now - ratholed into name/principal/token
[12:07:06] <leifj> jeff: let's climb out
[12:07:19] <leifj> jaltman: larry - do we agree what we talk about?
[12:08:00] <leifj> jaltman: how do you handle negative acls? in part. how are cross domain handles
[12:08:18] <leifj> larry: can give examples
[12:08:49] <leifj> larry jeff and jaltman ratholing on sourcecode
[12:09:29] <leifj> nico: asks q about how PAC changes when forrests are traversed
[12:09:56] --- ThOr101 has become available
[12:10:12] --- ThOr101 has left
[12:10:41] <leifj> larry: wrong concept - an identity is a principal does not change, rights change
[12:11:41] <leifj> nico: can a negative acl reference a group which is no longer in the PAC after traversing a forrest?
[12:11:48] <leifj> larry: misconfiguraiton?
[12:11:55] <leifj> nico: where?
[12:12:13] <leifj> larry: descirbes resource domains
[12:12:34] <leifj> nico: so misconfiguration is at the acl where the resource lives
[12:13:03] <leifj> larry: the ui won't allow you to make the misstake in the first place
[12:13:20] <leifj> nico: right but is this enforced by any kdc?
[12:13:53] <leifj> larry: yes <but with an explanation how>
[12:14:19] <leifj> <nico and larry continue this discussion clarifying>
[12:14:27] --- seema has become available
[12:15:57] <leifj> nico: summary - system disallows the use of negative acls referencing groups which are removed in traversing-...
[12:16:11] <leifj> <jeff tries to make better explanation>
[12:17:25] <leifj> jeff: windows won't let you set negative acls based on a group if there is a possiblity of getting a principal for that group that won' say the user is in the group
[12:18:13] <leifj> nico larry and jeff ellaborates on this
[12:19:16] <leifj> nico: put text in security considerations
[12:19:32] <leifj> (explaining what to think about for negativie acls)
[12:21:41] <leifj> jeff and nico discuss possible ways to formulate security considerations...
[12:21:49] <leifj> sam: leave this for list?
[12:22:01] <leifj> tom: don't understand what jeff is saying
[12:23:32] <leifj> nico: proposes solution
[12:23:47] <leifj> nico: nfsv4 comes later
[12:23:57] <leifj> next issue - tagged blobs vs native types
[12:24:01] <leifj> nico: comments?
[12:24:22] <leifj> jeff: not clear what you mean by native types?
[12:24:30] <leifj> sam: what are we doing here?
[12:25:08] <leifj> nico: way to reference native types inside gss
[12:25:11] <leifj> thypes
[12:25:34] <leifj> jaltman: enum types bad
[12:25:59] <leifj> jaltman: oids better but we need translation functions
[12:27:00] <leifj> jeff: it may be in scope, yes
[12:28:01] <leifj> jeff: must keep it extensible
[12:28:46] <leifj> nico: taged blogs is the way to go
[12:29:01] <leifj> jeff: and then what conversions are a part of gssapi
[12:29:05] <leifj> ?
[12:29:54] <leifj> nico and jeff continue the discuss
[12:30:19] <leifj> larry: more productive to consider what attribute will be useful
[12:30:28] <leifj> larry: before desgning the abstract api
[12:30:33] <leifj> nico and jeff disagree
[12:30:57] <leifj> sam: larry has a point - let's make sure we have implementable use-cases before publishing the api
[12:31:16] <leifj> bill: there will be muliptle use-cases
[12:31:54] <leifj> bill: sometimes you need things close to your os
[12:32:20] <leifj> nico: perhaps list attributes wo specifying conversion routines and native types
[12:32:42] <leifj> jeff and nico don't think possible to list useful attributes
[12:33:34] <leifj> nico: is there still (for instance) a draft on the MS PAC?
[12:33:40] <leifj> larry: yes but not current
[12:34:16] <leifj> larry: (point rasied in paris) - make sure an api already solved in windows, anything else would be irresponsible
[12:34:44] <leifj> rather: make sure we design an api which solves the problems already solved in windows
[12:36:11] <leifj> nico: there are general requirements also which don't map to what is present in any os
[12:36:34] <leifj> nico: believe the api already has what larry needs
[12:36:47] <leifj> larry: lets do case-study first
[12:37:10] <leifj> jaltman: discussion closed
[12:37:49] <nico> hi seemA
[12:38:39] <seema> hi
[12:39:06] <leifj> jaltman: gssv2 clarifications
[12:39:12] <leifj> (slide)
[12:41:04] <leifj> jaltman: need to combine text from several older documents
[12:41:40] <leifj> jaltman gets volounteers for online editing
[12:42:25] <leifj> <online editing starts>
[12:43:50] <nico> topic 1: Character-set issues
[12:44:04] <nico> - rfc 2744 refers to Latin-1
[12:44:29] <nico> rough proposal (mine): - remove reference to Latin-1 from C-bindings
[12:44:46] <nico> - add text to C-bindings and generic API to the effect of:
[12:45:46] <nico> - 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
[12:46:43] --- gregorylebo has become available
[12:46:56] --- jhutz has become available
[12:47:01] <raeburn> My notes on C binding issues are: - "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 Some is proposed text, some just a little discussion of issues for consideration. What should I send?
[12:47:30] <raeburn> GSS_C_AF_INET6 may be out of scope for this doc. ABI stuff too maybe...
[12:54:45] <raeburn> ** const 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.
[12:56:16] <raeburn> 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 interoperable ABI.
[12:56:32] <tlyu> OM_uint32 was poorly defined, and still is
[12:57:06] <nico> but isn't an ABI out of scope? I'd like to make some ABI-specific *recommendations* but not requirements
[12:57:15] <raeburn> ** GSS_C_AF_INET6 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...]
[12:57:24] <nico> also, perhaps we can abstract ABI differences into some #defines
[12:57:56] <raeburn> Yes, the ABI is probably out of scope, though Appendix B of RFC 2744 does discuss it.
[12:58:03] <tlyu> yeah, i guess it's an ABI issue, but "smallest natural unsigned integer type that provides at least 32 bits of precision" is still dreadfully underspecified
[13:00:36] <leifj> nico discusses cbindings and addresses
[13:01:53] <leifj> ken: encoding sould not depend on language binding
[13:02:28] <leifj> nico and ken discuss this issue
[13:04:20] <leifj> nico and ken disagree on wether language bindins can refer to eachother for type definitions
[13:04:52] <leifj> jaltman: this is an informational document - no new definitions
[13:07:37] <leifj> discussion continues on the scope of this document (now cbindings)
[13:08:05] <nico> so, as I understood ken's point: mechanisms are referencing C-bindings for some things that should be defined separately, and which the C bindings then could reference also where appropriate -- I don't disagree, but I don't think the current situation needs correcting
[13:11:46] <leifj> discussion about the scope and content of the document continues...
[13:12:35] <raeburn> ** 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 typedef names. 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 gssapi.h.
[13:18:01] --- nov has left
[13:19:03] <raeburn> ** 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. See also [Boehm] for a discussion of issues in attempting to discuss thread support without making it integral to the base language specification.
[13:19:24] <raeburn> Ref: Boehm, Hans-J. "Threads Cannot Be Implemented As a Library", conference proceedings, ACM SIGPLAN 2005 Conference on Programming Language Design and Implementation.
[13:21:37] --- gregorylebo has left: Replaced by new connection
[13:21:38] <nico> not ok for apps to assume thread safety on part of gss implementation
[13:21:48] <nico> apps must know
[13:24:04] <nico> channel bindings
[13:24:04] <nico> aaa
[13:25:29] <raeburn> revised paragraph: 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.
[13:25:50] <raeburn> does anyone care about the text re "const" i sent above?
[13:26:28] <leifj> discussion about cbindings
[13:26:56] <raeburn> where c == channel :-)
[13:29:41] --- hartmans has left
[13:30:03] <raeburn> we have a few seconds left... :-)
[13:32:36] <seema> I have few questions on GSS extensions
[13:33:50] <leifj> done
[13:34:38] --- tlyu has left
[13:34:39] <Jeffrey Altman> please send questions to the list
[13:34:42] --- lha has left
[13:34:54] <seema> ok
[13:34:56] <raeburn> sorry seema, we're breaking for lunch. we'll try to help on the mailing list...
[13:35:06] --- nico has left
[13:35:18] --- raeburn has left: Disconnected
[13:38:26] --- alexeymelnikov has left
[13:42:56] --- beuchelt has left: Logging off
[13:44:37] --- Jeffrey Altman has left
[13:48:12] --- jhutz has left
[13:51:45] --- leifj has left
[15:14:37] --- leifj has become available
[15:14:43] --- leifj has left
[15:34:53] --- seema has left