[00:08:15] --- raeburn has become available
[00:31:02] --- raeburn has left
[11:53:07] --- hartmans has become available
[12:32:30] --- hartmans has left: Disconnected
[13:53:38] --- jaltman has become available
[14:31:45] --- jas has become available
[14:39:53] --- jaltman has left: Disconnected
[14:42:13] --- jaltman has become available
[14:45:10] --- hartmans has become available
[15:17:52] --- pbh has become available
[16:29:30] --- jaltman has left: Disconnected
[16:33:39] --- jaltman has become available
[16:44:47] --- hartmans has left
[16:55:59] --- jaltman has left: Replaced by new connection
[16:57:15] --- pbh has left: Disconnected
[17:10:34] --- jaltman has become available
[17:11:13] --- pbh has become available
[17:16:33] --- rpayn422 has become available
[17:19:32] --- peterd has become available
[17:19:48] --- kenh has become available
[17:21:15] <kenh> Jeff Altman is opening the BOF.
[17:21:18] --- leg has become available
[17:21:37] <kenh> Introduction
[17:22:21] <kenh> Four years since CAT closed, wide deployment has revealed RFCs 2743 and 2744 to be less well-defined that they could be.
[17:23:09] --- hartmans has become available
[17:23:10] <kenh> E.g.: Credentials management, thread safety, channel bindings, ABI stability, mechanism specific extensibility, support for mechanisms without a single canonical name.
[17:23:34] --- raeburn has become available
[17:23:46] --- tlyu has become available
[17:23:56] <kenh> Jeff mispronounces my last name, as usual.
[17:24:22] <kenh> GSS-SPNEGO is flawed; it's not possible to creat interoperable implementations.
[17:24:37] --- warlord has become available
[17:25:13] <kenh> Channel bindings must be definedd to support crypto channels such as TLS, IPSec, SSH and a new GSS mechanism to negotiate channel bindings must be defined.
[17:25:20] <kenh> Language bindings for C# are desired.
[17:25:57] --- dumdidum has become available
[17:26:17] <kenh> What this BOF is going to try to do is to present some of the problem spaces, and see if enough work is available/appropriate for a WG.
[17:26:27] --- leifj has become available
[17:27:05] --- jhutz has become available
[17:27:37] <kenh> First presentation: Doug Engert, Argonne National Labs, presenting about Global Grid Forum & GSS extensions developed as part of the GGF.
[17:27:43] --- mlshore has become available
[17:28:06] <kenh> GGF formed about 5-6 years ago (http://www.ggf.org)
[17:28:33] <kenh> Standardization of Grid Computing, 400 Organizations/50 countries, next meeting in Brussels.
[17:28:39] <jas> [are presentations available online, for us participating over internet only?]
[17:28:55] <kenh> (To jas: Sorry, I don't believe so)
[17:29:08] <kenh> Characteristics of Grid Computing:
[17:29:24] <kenh> More than traditional client/server or distributed computing.
[17:29:33] <kenh> User-to-user, peer-to-peer authentication.
[17:29:42] <rpayn422> Can they be made available? (As a general question.)
[17:29:53] <kenh> Users may start servers/services, and two-way delegation.
[17:29:54] <hartmans> Yes but probably not in real time
[17:30:11] <kenh> The Globus GSI (http://www.globus.org)
[17:30:22] <kenh> A GSS-API implementation using TLS/SSL with X.509 certs.
[17:30:53] <kenh> Delegation using RFC-3820 "Internet X.509 PKI Proxy Certificate Profiles", similar to forwarded Kerberos tickets.
[17:31:06] <kenh> Initiator and accepter use similar creds.
[17:31:21] <kenh> Allows user-to-user and self-to-self authentication.
[17:32:18] <kenh> (e.g., file transfer between two nodes, using a proxy cert)
[17:32:30] --- mlshore has left
[17:32:36] <kenh> GSS-API Extensions GFD-E.024
[17:33:04] <kenh> http://www.ggf.org/documents/GWD-I-E/GFD-E.024.pdf
[17:33:29] <kenh> http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-01.txt
[17:33:47] <kenh> Describe GSS extensions adopted by GGF.
[17:33:55] <kenh> Details of extensionss:
[17:34:00] <kenh> Credential import/export.
[17:34:09] <kenh> Delegation at any time/direction.
[17:34:16] <kenh> Credential extensions handling.
[17:34:23] <kenh> Setting of context options.
[17:34:33] --- mstjohns has become available
[17:34:46] --- sommerfeld has become available
[17:35:20] <kenh> Credential import/export:
[17:35:35] <kenh> APIs: gss_export_cred(), gss_import_cred()
[17:35:58] <kenh> Credentials to a buffer, for things like application saves/reloads.
[17:36:13] <kenh> Credentials could be saved for use by non-GSS-API apps.
[17:36:45] <kenh> Applications must be able to accept mmultiple connections, and save/reload delegated creds not tied to process or thread.
[17:36:53] <kenh> Implemented for GSI and MIT Kerberos.
[17:37:23] <kenh> (Missing piece from MIT Kerberos is how to export creds within the GSSAPI)
[17:37:34] <kenh> Concerns with Nico Williams "Creds Store" document:
[17:37:48] <kenh> Needs more control by application over delegated creds.
[17:38:14] <kenh> (Uses implicit cred store, but does not address explicit creds stores under application control)
[17:38:39] <kenh> Refers to GGF GSI extensions implying that the mech needs knowledge of envionment
[17:38:56] <kenh> Uses Simon's OpenSSH mods as example, but they use KRB5CCNAME environement variable.
[17:39:21] <kenh> (Nico Wiilliams pointed out at this point that OpenSSH is a bad example, and it doesn't have to be done that way)
[17:39:26] --- admcd has become available
[17:39:28] <kenh> Delegation at any time:
[17:39:45] <kenh> gss_init_delegation(), gss_accept_delegation()
[17:40:10] <kenh> Allows credential delegatin after context establishment, may be different creds, delegation is in either direction.
[17:40:18] <kenh> Credential extensions handling:
[17:41:02] <kenh> Get mechanism or OID-specific information from credentials. Possible uses: Certificate extensions/Kerberos authorization data.
[17:41:22] <kenh> Use OID to avoid mechanism API calls.
[17:41:26] --- leifj has left: Replaced by new connection
[17:41:31] <kenh> Setting of context options:
[17:41:38] <kenh> gss_set_context_option_call()
[17:42:13] <kenh> Set options for context using an OID. E.g.: Limited delegation, Kerberos forwardable flag, what to do when context expires, set encryption options.
[17:42:25] <kenh> Additional functional desired:
[17:42:31] <kenh> Token Framing for every token.
[17:42:38] --- avri has become available
[17:42:48] <kenh> Levels of verbosity with gss_display_status().
[17:43:03] <kenh> Need a simple authz frunction to access krb5_kuserok() or the gridmap file.
[17:43:31] --- rlbob has become available
[17:43:44] <kenh> The End.
[17:43:58] <kenh> No questions at this time.
[17:44:49] <kenh> Jeff Altman: the GGF people have touched on issues that numerous people have discovered (e.g., credential handling, authorization issues).
[17:45:29] <kenh> jaltman: Perhaps given our experience, we can tackle broader problems with more comfort than we had in the past.
[17:45:43] <kenh> First presentation by Sam Hartman (no slides)
[17:45:55] <kenh> Sam: GSS-API has concept called channel bindings.
[17:46:30] <kenh> Want to be able to make an assertion that the channel you are communication over is the same one you authenticated across.
[17:47:02] <kenh> GSS-API authors had the concept that you might want to bind to a crypto key you're using for encryption, but they didn't really follow through.
[17:47:31] --- ohm has become available
[17:47:33] <kenh> In RFC 2743, GSSAPI split into language-independent and language-dependent sections.
[17:47:36] --- leg has left: Replaced by new connection
[17:47:36] --- leg has become available
[17:47:36] --- leg has left
[17:48:17] <kenh> The language-independent portion treated channel bindings as an opaque blob, but it's the sort of thing that mechanisms want to peek into.
[17:48:49] <kenh> The C-language bindings specified a IP address, and the format for the IP address.
[17:49:37] <kenh> The revision to the base specification refers to the C-language bindings and says, "Look her to see how channel bindings work". obviously, this is odd.
[17:50:19] <kenh> The language bindings defines a C structure, which is not a good presentation layer (other minor problems with channel bindings).
[17:50:30] <kenh> Sam's second presentation: Naming issues with GSSAPI
[17:50:54] <kenh> (works well for some apps, not so well for others).
[17:51:05] <kenh> Authentication/Authorization:
[17:51:25] <kenh> Authentication generates assertions as input to authorizations
[17:51:38] <kenh> Authorization uses these assertions to make access decisions.
[17:51:45] <kenh> GSS AUthentication model:
[17:51:53] <kenh> GSSAPI asserts an authenticated name to both peers.
[17:52:19] <kenh> All input forms of this name can be canonicalized to a single form which is binary comparable.
[17:52:31] --- pbh has left: Replaced by new connection
[17:52:31] <kenh> Authorization with GSSAPI names:
[17:52:32] --- pbh has become available
[17:52:32] --- pbh has left
[17:52:41] <kenh> Canonical forms can be placed on ACLs.
[17:52:51] <kenh> Without authentication a peer can generate canonical forms.
[17:52:58] <kenh> More complicated structures.
[17:53:15] <kenh> You might want to do more complicated things (directories, groups).
[17:53:16] --- pbh has become available
[17:53:25] <kenh> Difficulty of Canonical Forms:
[17:53:31] <kenh> Names change over time.
[17:53:57] <kenh> Some mechanisms have no canonical representations.
[17:54:19] --- admcd has left
[17:54:52] <kenh> (e.g., what is the canonical name out of an X.509 cert?)
[17:57:13] --- leg has become available
[17:57:14] <kenh> SubjectAltName creates problems for certificates.
[17:57:14] <kenh> (e.g., what about email address? Does the GSSAPI not get access to that because it's not part of your DN?)
[17:57:14] <kenh> (Comment from Bob Morgan: Some cases it's desirable to have the authentication name have only short-term value)
[17:57:26] <kenh> (comment from Bill Sommerfeld: I realized that if you looked at the X.509 extended key usage attribute, the cert became a lot more understandable, which means that should also be part of the cert's name)
[17:57:46] <kenh> Desire for new Authentication Assertions:
[17:57:51] <kenh> Membership in groups.
[17:58:05] <kenh> Liberty/SAML require more complex assertions
[17:58:12] --- ohm has left
[17:58:13] <kenh> Keeping names the same as people move in organizations.
[17:58:27] <sommerfeld> correction: If you look at X.509 EKU as part of the principal name, the justification for its existance became reasonable...
[18:00:21] <kenh> People that have done large Kerberos deployments don't want to look up authz data in directories, they want the info in tickets.
[18:00:44] <kenh> (Comment from Doug Engert: line between groups and names isn't black & white)
[18:00:50] <kenh> Possible solutions:
[18:00:57] <kenh> Name attributes
[18:01:04] <kenh> Extensions to gss_canonicalize_name()
[18:01:09] <kenh> Credential extensions.
[18:01:58] <kenh> (Name attributes: Reviewed by Martin Rex, he brough up a number of things that were already in there).
[18:02:43] <kenh> Extensions to gss_canonicalize_name() - pretty close to name attributes.
[18:02:58] --- Kurt has become available
[18:03:22] <kenh> (Comment from Nico Williams): Like first two solutions (name attributes, extensions to gss_canonicalize_name())
[18:03:57] --- ohm has become available
[18:03:57] <kenh> Presentation from Nico Williams: Channel Bindings
[18:04:15] <kenh> Introduction:
[18:04:24] --- rpayn422 has left: Replaced by new connection
[18:04:47] <kenh> Channel bindings allow session protecction at one network layer to be delegated to session protection at another by proving there is no MITM in the lower layer.
[18:04:54] --- rpayne has become available
[18:04:59] <kenh> Why? Performance plus security.
[18:05:23] <kenh> Concept first described in GSS-APIv2 (rfc2273/2274), but the specs were lacking.
[18:06:43] <kenh> (This is really relevant for applications that already have transport security, e.g. hardware accelerated encryption)
[18:07:10] <kenh> Formal Definition (rough; See I-D)
[18:07:15] <kenh> Mutual auth at app-layer
[18:07:39] <kenh> App-level end-points exchange integrity-protected proof of knowledge of "channel bindings" for lower layer, secure channel.
[18:07:49] <kenh> Channel bindings must cryptographically _name_ a channel.
[18:07:59] <kenh> Examples: TLS, SSHv2
[18:08:10] <kenh> Channel bindings for TLS: client & server finished messages
[18:08:18] <kenh> Channel bindings for SSHv2: session ID
[18:08:41] <kenh> These are crypto bound to the initial TLS/SSHv2 key exchange.
[18:08:42] --- mstjohns has left: Replaced by new connection
[18:08:42] --- mstjohns has become available
[18:08:43] --- mstjohns has left
[18:09:06] <kenh> TCP/SCTP/UDP/IPSec? It can be done.
[18:09:11] --- mstjohns has become available
[18:09:20] <kenh> NULL bindings? Better than AUTH_SYS for NFS.
[18:09:32] <kenh> GSS-API & Channel Bindings.
[18:09:46] <kenh> RFC2743 talks about them, but provides little guidance.
[18:09:57] --- mstjohns has left: Disconnected
[18:10:12] <kenh> RFC2744 provides C structure (and little guidance beyond network addresses)
[18:10:29] <kenh> channel binding are _not_ negotiable - you either use them, or don't.
[18:10:44] <kenh> To make GSS channel bindings useful, we did:
[18:10:54] <kenh> - Provide a generic structure for channel binding data
[18:11:11] <kenh> - Provide guidance for several types of channel bindings
[18:11:33] <kenh> - Provide for negotiation of channel bindings by adding a new stackable GSS mechanism.
[18:11:34] --- ekr has become available
[18:11:42] <kenh> Benfits (Overview)
[18:11:51] <kenh> Avoid double encryption when possible
[18:11:58] <kenh> (E.g., NFS over IPsec)
[18:12:08] <kenh> And without Channel Bindings?
[18:12:27] <kenh> If the lower layer authentication facilities satisfy application needs then there's no need for channel bindings.
[18:12:41] <kenh> But we expect IPsec w/user certs to be rare.
[18:12:42] --- ekr has left
[18:12:49] <kenh> Performance benefits: RDDP
[18:13:37] <kenh> RDDP layers between the transport and the application to facilitate receiver zero-copy by addressing interesting buffers in app payloads and direction RNIC to DMA data to correct location.
[18:14:22] <kenh> IPSec channel: TCP/SCTP connection protected with transport-mode SA's with same protection/authentication for duration of connection.
[18:14:31] <kenh> New APIs needed to deal with IPsec channels.
[18:15:29] <kenh> (e.g. draft-ietf-ipsec-apireq-00.txt)
[18:15:47] <kenh> What about anonymous IPsec?
[18:16:11] <kenh> Apps that provide for authentication may not care about IDs authentication by IPsec.
[18:16:44] <kenh> But it would be nice to leverage IPsec for encryption (think hardware encryption).
[18:17:16] <kenh> Channel binding structure/constructor functions.
[18:17:39] <kenh> draft-williams-gssapi-channel-bindings-00.txt (not yet published)
[18:17:55] <kenh> Generalizes structures from RFC2374.
[18:18:05] <kenh> CCM-BIND: GSS pseudo mechanism
[18:18:17] <kenh> stacks atop concrete mechs, like Kerberos 5.
[18:18:24] <kenh> draft-ietf-nfsv4-ccm-02.txt
[18:18:41] <kenh> Properlyu handles channel bindings proof exchanges.
[18:18:55] <kenh> Offering CCM signals willingness to use channel bindings.
[18:18:59] --- peterd has left: Disconnected
[18:19:21] <kenh> SASL w/Channel Bindings
[18:19:28] <kenh> Use SASL GSS-API spec
[18:19:45] <kenh> And use CCM-BIND, negotiate SASL mechs as usual.
[18:20:16] <kenh> SPNEGO and channel bindings: pretty much same as SASL (minor changes to SPNEGO)
[18:20:59] <hartmans> How behind are we? We should make sure we get to discuss the charter;)
[18:21:13] <kenh> (no idea, jaltman should know)
[18:21:48] <kenh> In designing GSS CCM, useful concept noted: generic stackable pseudo-mechs.
[18:22:00] <kenh> Interfaces needed to make this work.
[18:22:45] --- avri has left
[18:22:57] <jas> (Is draft-williams-gssapi-channel-bindings-00.txt available somewhere? I wonder how it can achieve channel bindings in SASL when the SASL GSS-API demand NULL channel bindings.)
[18:23:07] <raeburn> I think we're pretty close to on schedule.
[18:23:58] <kenh> David Black, EMC: IPsec channel bindings can get very "interesting", e.g. fiberchannel node names in IPsec endpoint names.
[18:24:02] <hartmans> It's available in the id repository
[18:24:21] <hartmans> I think the SASL text is possibly weak; I don't think the SASL community has reviewed
[18:24:22] <kenh> Nico: We don't care what the channel bindings are at the IPsec layer.
[18:25:32] <kenh> David: Not time for full discussion now, just wanted to bring up the issue that the idea of indirect cryptographic binding involves a lot of work.
[18:25:55] <kenh> Second presentation by Nico: Stackable GSS mechanisms
[18:26:09] <kenh> Brief history:
[18:26:21] --- Kurt has left
[18:26:27] <kenh> 2000 - LIPKEY, basic-over-SPKM
[18:26:28] <jas> Re williams-gssapi-channel-bindings: Do you have a URL? I thought it hadn't been submitted yet.
[18:26:51] <kenh> Early 2003: CCM-BIND (I-D), first stackable GSS pseudo-mechanism.
[18:27:01] <hartmans> No, the new version hadn't been submitted
[18:27:20] <kenh> 58th IETF: hallway discussion of mechanism resulted in need for abstraction.
[18:27:25] <hartmans> hold on
[18:27:37] <kenh> Glossary: Concrete mechanism - Mech that can be used as-is.
[18:28:02] <kenh> Pseudo-mech: mech only useful without reference to a concrete mech (e.g., SPNEGO)
[18:28:18] <hartmans> No, I'm wrong. nfsv4-channel-bindings is what exists of williams-channel-bindings today.
[18:28:28] <hartmans> Nico may have sent the other draft to the list
[18:28:31] <kenh> stackable pseudo-mech: mechanism that can be stacked above or combined with a concrete mechanism.
[18:28:34] <kenh> Introduction:
[18:29:09] --- jjavip has become available
[18:29:14] <kenh> GSS-API mechs exist for Kerberos 5, PKIX (SPKM), and others such as MS NTLMSSP, Sun's mech_dh.
[18:29:15] <jas> Ok, thanks.
[18:29:31] <kenh> GSS pseudo-mechanisms exist today - SPNEGO.
[18:30:12] <kenh> When developing new lightweight pseudo-mech for NFS we expanded on channel bindings and came up with CCM.
[18:30:24] <kenh> Composite mechs have OID, just like any other mechanism.
[18:31:03] <kenh> LIPKEY: Almost a stack (does equivalant of basic-over-SSL)
[18:31:15] <kenh> Other idea for stackable pseudo-mechs:
[18:31:24] <kenh> Proper channel binding - CCM-BIND
[18:31:40] <kenh> PFS, Compression, basic-over-*, three party auth.
[18:32:16] <kenh> Example: Perfect Forward Secrecy.
[18:32:47] <kenh> Context tokens might contain tokens from lower mech, DH public parameters, and it's own per-message tokens.
[18:33:16] <kenh> Not all mechanism stacks make sense (e.g., pfs, compress, krb5 is no good, but {compress, pfs, krb5} is okay.
[18:33:31] <kenh> Complexity - how many valid composites, how to negotiate?
[18:34:00] <kenh> GSS_indicate_mechs() - don't want to make stackable mechs available to apps.
[18:34:21] <kenh> Solutions:
[18:34:37] --- peterd has become available
[18:34:39] --- jjavip has left: Replaced by new connection
[18:34:39] --- jjavip has become available
[18:34:52] <kenh> GSS_indicate_mechs() MUST not indicate stackable mechs and composite mechs (composite mechs okay if explicitly configured to do so).
[18:35:00] <kenh> New APIs for stackable/composite mechs.
[18:35:23] <kenh> Composite mech users know what features they want from them,, but why should the knnow the OID of the composite mechs?
[18:35:44] <kenh> Add API for inquiring mechs by attributes.
[18:35:55] <kenh> These new APIs are all optional.
[18:36:30] --- jis has become available
[18:36:40] <kenh> Stackable pseudo-mechs should describe constraints on how they can be mixed with others.
[18:36:51] <kenh> Benefits of new APIs:
[18:37:01] <kenh> No need to hardcode mechanism OIDs anymore.
[18:37:23] <kenh> e.g, SSHv2 MUST NOT use SPNEGO, but SPNEGO might get new OIDs.
[18:37:39] <kenh> Indicating mechs by attributes makes applications more general.
[18:37:51] <kenh> New APIs (see slides for details, I can't type that fast)
[18:38:55] <kenh> Mechanism attributes: concrete, stackable, composite, glue, other.
[18:39:14] <kenh> Depreciated (old krb5 mech OID), non-standard (GSI SSL mech)
[18:39:28] <kenh> authenticates initiator, acceptor, other.
[18:40:14] <kenh> draft-williams-gssapi-stackable-pseudo-mechs-00.txt
[18:40:30] <kenh> No questions;
[18:40:45] <kenh> next presentation: Wyllys Ingersoll, Sun Microsystems.
[18:40:55] --- jjavip has left: Replaced by new connection
[18:40:56] --- jjavip has become available
[18:41:57] <kenh> Change of plans: discussion of C# language bindings by J.K. of Microsoft.
[18:42:10] <kenh> Not able to get draft out in time.
[18:42:53] <kenh> First version is just a description of MS's implementation of current GSS-API bindings.
[18:43:03] <kenh> We are hoping that this will be the right forum.
[18:43:22] <kenh> Interested in hearing from people who had experience with Java GSSAPI bindings.
[18:43:51] --- fp has become available
[18:43:57] <kenh> Comment from Nico: Seems to me that language bindings are not that hard to design, not sure if you need a WG to do the work, but it may not add much load to the working group.
[18:44:15] <sommerfeld> api's are hard
[18:44:51] <kenh> Nico: If you publish it somewhere else, informational draft here would be nice, but have no strong opinion either way.
[18:45:32] <kenh> Nico: If you're going to have bindings for SSPI's encrypt-in-place functionality, it would be nice to have that functionality in GSSAPI as well.
[18:46:08] <kenh> Now, presentation from Wyllys:
[18:46:23] <kenh> Original SPNEGO draft implemented early on by MS.
[18:46:52] <kenh> When Sun tried to implement it, discovered interop problems with MS implementation.
[18:47:51] <kenh> Some problems are DER versus BER, explicit versus implicit tagging, mechlist MIC field, only implemented to cover initial list you send (should it also include flags, encoding of the sequence, concatenated OIDs), and more vagarities.
[18:48:02] <kenh> (Those were all spec issues)
[18:48:08] --- dinakar has become available
[18:48:28] <kenh> Implementation issues: Kerberos OID is wrong, off by one byte, which changes whole OID.
[18:48:33] --- Kurt has become available
[18:49:20] <kenh> Mechlist MIC field not valid for request, and server ignores mechlist MIC field completely.
[18:49:35] --- fp has left
[18:50:28] <kenh> (Problem with server ignoring mechlist MIC is that since the sequence number is incremented on the client but the server does not, the sequence numbers don't match)
[18:50:45] <kenh> Without using mechlist-MIC, you get SNEGO, not SPNEGO.
[18:51:22] <kenh> We couldn't find a way of producing a backwards-compatible implementation that followed the spec and interoperated with MS.
[18:51:28] <hartmans> And that's "secure" single sign-on
[18:51:51] <warlord> "backwards compatible" with what?
[18:52:00] <sommerfeld> "secure" "single" "sign"-"on"
[18:52:20] <hartmans> Microsoft
[18:52:44] <kenh> One suggestion is to have a flag day among vendors, but that won't likely work.
[18:52:55] <hartmans> Bill, good point. I can think of ways in which each of those words doesn't apply to the http negotiate mech.
[18:52:55] <kenh> Another suggestion is to clarify spec and get a new OID.
[18:53:30] <hartmans> Even if you have a new OID, you need to have a flag day
[18:53:41] <kenh> End of Wyllys's presentation, slides available later.
[18:54:16] <kenh> jaltman: Proposed charter.
[18:55:05] <kenh> Looking at moving two directions at once: informational draft with wisdom for gssapi v2, new draft describing gssapi v3.
[18:56:21] --- jis has left: Disconnected
[18:58:57] <kenh> Paul (?), Cisco: are we voting on this whole thing as one basket, or on individual pieces?
[18:59:23] <kenh> Nico: The only thing that might break backwards compat is the naming work (no canonical names for some mechs).
[18:59:33] <kenh> (just as a clarification)
[19:00:18] --- jjavip has left: Disconnected
[19:00:44] <kenh> Open mike for charter items:
[19:00:49] --- peterd has left
[19:01:16] <kenh> Joe Saloway, Cisco: W.R.T channel bindings, might be worth investigating of we can get some commonality from SASL & EAP.
[19:01:19] --- leg has left: Disconnected
[19:01:56] <kenh> Joe: In terms of naming, might need to update existing mechanisms to deal with new naming.
[19:02:06] <kenh> jaltman: agreed, naming is an open topic still.
[19:02:44] <kenh> Sam Hartman: The SASL GSSAPI editor is very familiar with our work (couldn't be here today), it would be great if we could get someone from EAP here.
[19:03:21] <kenh> sam: w.r.t naming, if a mechanism has a home, the work could be done there (e.g., Kerberos in krb-wg), not sure if spkm has a home.
[19:03:50] <kenh> sam: if people want to drop things, my personal preference is to drop gssapiv2 clarifications.
[19:04:25] <kenh> nico: w.r.t. channel bindings, I don't think the concept is specific to gssapi, can be generalized to other things. GSSAPI just provides a slot for it, so it's a natural home for it.
[19:05:32] <kenh> sommerfeld: There may be multiple working groups here (e.g., maybe channel bindings should be it's own WG). Maybe want broader community to work on channel bindings who may not be interested in 'const' in GSSAPI.
[19:06:29] <kenh> Unknown: May want to check to see if termology w.r.t. channel bindings is same termology as EAP, not sure if it is.
[19:06:34] <hartmans> EAP has the same chanel bindings problems even if they don't call it channel bindings.
[19:07:22] --- dinakar has left: Disconnected
[19:07:24] <kenh> Joe saloway: there are a couple of drafts that deal with things similar to stackable mechs in EAP.
[19:07:42] <kenh> nico: Similar things in Kerberos with preauth mechanisms.
[19:08:53] --- Kurt has left
[19:09:12] <jas> Charter: "Specify thread safety extensions"? Has focus shifted from clarifying thread issues (like two threads calling gss_get_mic at the same time), to provide new APIs? What would the new APIs look like? I re-read the thread discussion on the list, but did not find discussion on any thread extensions.
[19:09:41] <kenh> sam: while it's good we're acknowledging all of this synergy, we do want to get done in a finite time, if we split off into multiple wg's it may prevent that.
[19:10:28] --- admcd has become available
[19:11:08] <kenh> answer to jas's question (from jaltman): I do not believe we're discussing any new APIs.
[19:11:21] <kenh> Nico: We're just talking about changes in semantics.
[19:11:52] <kenh> Nico: But some list members believe that's effectively a new API.
[19:12:37] <kenh> Nico: The big issue is that if you write a threaded GSSAPI program, you lose portability.
[19:13:33] <kenh> Ken Raeburn: Phrasing of this section of charter (clarification of gssapi v2) is poor; many times, if something is unclear, the answer is, "You just lose".
[19:14:17] <kenh> jaltman: Idea is similar to Kerberos clarifications: explanations of what apps might expect, and what we thought the spec meant.
[19:15:07] <jas> fwiw, changing semantics to make threaded use work would be fine by me, but introducing new APIs for threading seem convoluted.
[19:15:12] <kenh> nico: GSSAPIv3 won't be radically different than v2; should have most of the same APIs. For v2, we could use a preprocessor macro to determine if the GSSAPI implementation is thread-safe or not.
[19:15:21] --- rlbob has left
[19:15:47] <kenh> jas: Everyone agrees with you, and we are not proposing creating new APIs for that purpose.
[19:17:13] <kenh> Russ Housley (IESG): First big question: Is there community support for this initiative? Some documents already have names behind them, which means that they have editors.
[19:17:40] --- admcd has left
[19:17:55] --- raeburn has left: Disconnected
[19:18:03] <kenh> Russ: Question asked: Do people think that this belongs in the IETF? Looks like the consensus is that the answer is "yes".
[19:18:10] --- tlyu has left: Logged out
[19:18:10] --- hartmans has left
[19:18:21] --- kenh has left
[19:18:32] --- dumdidum has left
[19:19:20] --- pbh has left
[19:20:19] --- warlord has left
[19:21:19] --- rpayne has left
[19:25:06] --- jas has left
[19:25:09] --- jaltman has left
[19:26:55] --- ohm has left
[19:45:46] --- jhutz has left: Disconnected
[21:12:57] --- leg has become available
[21:13:42] --- leg has left: Replaced by new connection
[21:13:43] --- leg has become available
[21:13:43] --- leg has left
[22:49:24] --- sommerfeld has left
[23:02:03] --- tlyu has become available
[23:02:25] --- tlyu has left