Subject: Jabber Log/Minutes from IETF-60 Kitten BOF

From: Jeffrey Altman <[email-masked]>
Date: Mon, 02 Aug 2004 17:33:58 -0700

Thank you to Ken Hornstein for being scribe.

[14:45] jaltman has entered the room.

[14:45] kitten

[14:45] jas has entered the room.

[14:45] hartmans has entered the room.

[14:45] pbh has entered the room.

[14:56] hartmans has left the room.

You have been disconnected.

You have been disconnected.

You have been disconnected.

You have been disconnected.

Reconnected.

[15:22] jaltman has entered the room.

[15:22] kitten

[15:22] jas has entered the room.

[15:22] pbh has entered the room.

[15:28] rpayn422 has entered the room.

[15:31] peterd has entered the room.

[15:31] kenh has entered the room.

[15:32]<kenh> Jeff Altman is opening the BOF.

[15:32] leg has entered the room.

[15:33]<kenh> Introduction

[15:34]<kenh> Four years since CAT closed, wide deployment has
revealed RFCs 2743 and 2744 to be less well-defined that they could be.

[15:34] hartmans has entered the room.

[15:34]<kenh> E.g.: Credentials management, thread safety,
channel bindings, ABI stability, mechanism specific extensibility,
support for mechanisms without a single canonical name.

[15:35] raeburn has entered the room.

[15:35] tlyu has entered the room.

[15:35]<kenh> Jeff mispronounces my last name, as usual.

[15:36]<kenh> GSS-SPNEGO is flawed; it's not possible to creat
interoperable implementations.

[15:36] warlord has entered the room.

[15:36]<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.

[15:37]<kenh> Language bindings for C# are desired.

[15:37] dumdidum has entered the room.

[15:37]<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.

[15:38] leifj has entered the room.

[15:38] jhutz has entered the room.

[15:39]<kenh> First presentation: Doug Engert, Argonne National
Labs, presenting about Global Grid Forum & GSS extensions developed
as part of the GGF.

[15:39] mlshore has entered the room.

[15:39]<kenh> GGF formed about 5-6 years ago (http://www.ggf.org)

[15:40]<kenh> Standardization of Grid Computing, 400
Organizations/50 countries, next meeting in Brussels.

[15:40]<jas> [are presentations available online, for us
participating over internet only?]

[15:40]<kenh> (To jas: Sorry, I don't believe so)

[15:40]<kenh> Characteristics of Grid Computing:

[15:41]<kenh> More than traditional client/server or distributed
computing.

[15:41]<kenh> User-to-user, peer-to-peer authentication.

[15:41]<rpayn422> Can they be made available?  (As a general
question.)

[15:41]<kenh> Users may start servers/services, and two-way
delegation.

[15:41]<hartmans> Yes but probably not in real time

[15:41]<kenh> The Globus GSI (http://www.globus.org)

[15:42]<kenh> A GSS-API implementation using TLS/SSL with X.509
certs.

[15:42]<kenh> Delegation using RFC-3820 "Internet X.509 PKI Proxy
Certificate Profiles", similar to forwarded Kerberos tickets.

[15:42]<kenh> Initiator and accepter use similar creds.

[15:43]<kenh> Allows user-to-user and self-to-self authentication.

[15:43]<kenh> (e.g., file transfer between two nodes, using a
proxy cert)

[15:44] mlshore has left the room.

[15:44]<kenh> GSS-API Extensions GFD-E.024

[15:44]<kenh> http://www.ggf.org/documents/GWD-I-E/GFD-E.024.pdf

[15:45]<kenh>
http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-01.txt

[15:45]<kenh> Describe GSS extensions adopted by GGF.

[15:45]<kenh> Details of extensionss:

[15:45]<kenh> Credential import/export.

[15:45]<kenh> Delegation at any time/direction.

[15:45]<kenh> Credential extensions handling.

[15:46]<kenh> Setting of context options.

[15:46] mstjohns has entered the room.

[15:46] sommerfeld has entered the room.

[15:47]<kenh> Credential import/export:

[15:47]<kenh> APIs: gss_export_cred(), gss_import_cred()

[15:47]<kenh> Credentials to a buffer, for things like
application saves/reloads.

[15:47]<kenh> Credentials could be saved for use by non-GSS-API
apps.

[15:48]<kenh> Applications must be able to accept mmultiple
connections, and save/reload delegated creds not tied to process or
thread.

[15:48]<kenh> Implemented for GSI and MIT Kerberos.

[15:49]<kenh> (Missing piece from MIT Kerberos is how to export
creds within the GSSAPI)

[15:49]<kenh> Concerns with Nico Williams "Creds Store" document:

[15:49]<kenh> Needs more control by application over delegated
creds.

[15:49]<kenh> (Uses implicit cred store, but does not address
explicit creds stores under application control)

[15:50]<kenh> Refers to GGF GSI extensions implying that the mech
needs knowledge of envionment

[15:50]<kenh> Uses Simon's OpenSSH mods as example, but they use
KRB5CCNAME environement variable.

[15:51]<kenh> (Nico Wiilliams pointed out at this point that
OpenSSH is a bad example, and it doesn't have to be done that way)

[15:51] admcd has entered the room.

[15:51]<kenh> Delegation at any time:

[15:51]<kenh> gss_init_delegation(), gss_accept_delegation()

[15:51]<kenh> Allows credential delegatin after context
establishment, may be different creds, delegation is in either
direction.

[15:52]<kenh> Credential extensions handling:

[15:52]<kenh> Get mechanism or OID-specific information from
credentials.  Possible uses: Certificate extensions/Kerberos
authorization data.

[15:53]<kenh> Use OID to avoid mechanism API calls.

[15:53] leifj has left the room.

[15:53]<kenh> Setting of context options:

[15:53]<kenh> gss_set_context_option_call()

[15:53]<kenh> Set options for context using an OID.  E.g.:
Limited delegation, Kerberos forwardable flag, what to do when context
expires, set encryption options.

[15:54]<kenh> Additional functional desired:

[15:54]<kenh> Token Framing for every token.

[15:54] avri has entered the room.

[15:54]<kenh> Levels of verbosity with gss_display_status().

[15:54]<kenh> Need a simple authz frunction to access
krb5_kuserok() or the gridmap file.

[15:55] rlbob has entered the room.

[15:55]<kenh> The End.

[15:55]<kenh> No questions at this time.

[15:56]<kenh> Jeff Altman: the GGF people have touched on issues
that numerous people have discovered (e.g., credential handling,
authorization issues).

[15:57]<kenh> jaltman: Perhaps given our experience, we can
tackle broader problems with more comfort than we had in the past.

[15:57]<kenh> First presentation by Sam Hartman (no slides)

[15:57]<kenh> Sam: GSS-API has concept called channel bindings.

[15:58]<kenh> Want to be able to make an assertion that the
channel you are communication over is the same one you authenticated
across.

[15:58]<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.

[15:59] ohm has entered the room.

[15:59]<kenh> In RFC 2743, GSSAPI split into language-independent
and language-dependent sections.

[15:59] leg has left the room.

[15:59] leg has entered the room.

[15:59] leg has left the room.

[15:59]<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.

[16:00]<kenh> The C-language bindings specified a IP address, and
the format for the IP address.

[16:01]<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.

[16:02]<kenh> The language bindings defines a C structure, which
is not a good presentation layer (other minor problems with channel
bindings).

[16:02]<kenh> Sam's second presentation: Naming issues with GSSAPI

[16:02]<kenh> (works well for some apps, not so well for others).

[16:02]<kenh> Authentication/Authorization:

[16:03]<kenh> Authentication generates assertions as input to
authorizations

[16:03]<kenh> Authorization uses these assertions to make access
decisions.

[16:03]<kenh> GSS AUthentication model:

[16:03]<kenh> GSSAPI asserts an authenticated name to both peers.

[16:04]<kenh> All input forms of this name can be canonicalized
to a single form which is binary comparable.

[16:04] pbh has left the room.

[16:04]<kenh> Authorization with GSSAPI names:

[16:04] pbh has entered the room.

[16:04] pbh has left the room.

[16:04]<kenh> Canonical forms can be placed on ACLs.

[16:04]<kenh> Without authentication a peer can generate
canonical forms.

[16:04]<kenh> More complicated structures.

[16:04]<kenh> You might want to do more complicated things
(directories, groups).

[16:04] pbh has entered the room.

[16:05]<kenh> Difficulty of Canonical Forms:

[16:05]<kenh> Names change over time.

[16:05]<kenh> Some mechanisms have no canonical representations.

[16:06] admcd has left the room.

[16:06]<kenh> (e.g., what is the canonical name out of an X.509
cert?)

[16:08] leg has entered the room.

[16:08]<kenh> SubjectAltName creates problems for certificates.

[16:08]<kenh> (e.g., what about email address?  Does the GSSAPI
not get access to that because it's not part of your DN?)

[16:08]<kenh> (Comment from Bob Morgan: Some cases it's desirable
to have the authentication name have only short-term value)

[16:09]<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)

[16:09]<kenh> Desire for new Authentication Assertions:

[16:09]<kenh> Membership in groups.

[16:09]<kenh> Liberty/SAML require more complex assertions

[16:09] ohm has left the room.

[16:09]<kenh> Keeping names the same as people move in
organizations.

[16:10]<sommerfeld> correction: If you look at X.509 EKU as part
of the principal name, the justification for its existance became
reasonable...

[16:12]<kenh> People that have done large Kerberos deployments
don't want to look up authz data in directories, they want the info in
tickets.

[16:12]<kenh> (Comment from Doug Engert: line between groups and
names isn't black & white)

[16:12]<kenh> Possible solutions:

[16:12]<kenh> Name attributes

[16:12]<kenh> Extensions to gss_canonicalize_name()

[16:12]<kenh> Credential extensions.

[16:13]<kenh> (Name attributes: Reviewed by Martin Rex, he brough
up a number of things that were already in there).

[16:14]<kenh> Extensions to gss_canonicalize_name() - pretty
close to name attributes.

[16:14] Kurt has entered the room.

[16:15]<kenh> (Comment from Nico Williams): Like first two
solutions (name attributes, extensions to gss_canonicalize_name())

[16:15] ohm has entered the room.

[16:15]<kenh> Presentation from Nico Williams: Channel Bindings

[16:15]<kenh> Introduction:

[16:16] rpayn422 has left the room.

[16:16]<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.

[16:16] rpayne has entered the room.

[16:16]<kenh> Why? Performance plus security.

[16:17]<kenh> Concept first described in GSS-APIv2
(rfc2273/2274), but the specs were lacking.

[16:18]<kenh> (This is really relevant for applications that
already have transport security, e.g. hardware accelerated encryption)

[16:18]<kenh> Formal Definition (rough; See I-D)

[16:18]<kenh> Mutual auth at app-layer

[16:19]<kenh> App-level end-points exchange integrity-protected
proof of knowledge of "channel bindings" for lower layer, secure
channel.

[16:19]<kenh> Channel bindings must cryptographically _name_ a
channel.

[16:19]<kenh> Examples: TLS, SSHv2

[16:19]<kenh> Channel bindings for TLS: client & server
finished messages

[16:20]<kenh> Channel bindings for SSHv2: session ID

[16:20]<kenh> These are crypto bound to the initial TLS/SSHv2 key
exchange.

[16:20] mstjohns has left the room.

[16:20] mstjohns has entered the room.

[16:20] mstjohns has left the room.

[16:20]<kenh> TCP/SCTP/UDP/IPSec? It can be done.

[16:20] mstjohns has entered the room.

[16:21]<kenh> NULL bindings?  Better than AUTH_SYS for NFS.

[16:21]<kenh> GSS-API & Channel Bindings.

[16:21]<kenh> RFC2743 talks about them, but provides little
guidance.

[16:21] mstjohns has left the room.

[16:21]<kenh> RFC2744 provides C structure (and little guidance
beyond network addresses)

[16:22]<kenh> channel binding are _not_ negotiable - you either
use them, or don't.

[16:22]<kenh> To make GSS channel bindings useful, we did:

[16:22]<kenh> - Provide a generic structure for channel binding
data

[16:22]<kenh> - Provide guidance for several types of channel
bindings

[16:23]<kenh> - Provide for negotiation of channel bindings by
adding a new stackable GSS mechanism.

[16:23] ekr has entered the room.

[16:23]<kenh> Benfits (Overview)

[16:23]<kenh> Avoid double encryption when possible

[16:23]<kenh> (E.g., NFS over IPsec)

[16:23]<kenh> And without Channel Bindings?

[16:24]<kenh> If the lower layer authentication facilities
satisfy application needs then there's no need for channel bindings.

[16:24]<kenh> But we expect IPsec w/user certs to be rare.

[16:24] ekr has left the room.

[16:24]<kenh> Performance benefits: RDDP

[16:25]<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.

[16:26]<kenh> IPSec channel: TCP/SCTP connection protected with
transport-mode SA's with same protection/authentication for duration of
connection.

[16:26]<kenh> New APIs needed to deal with IPsec channels.

[16:27]<kenh> (e.g. draft-ietf-ipsec-apireq-00.txt)

[16:27]<kenh> What about anonymous IPsec?

[16:27]<kenh> Apps that provide for authentication may not care
about IDs authentication by IPsec.

[16:28]<kenh> But it would be nice to leverage IPsec for
encryption (think hardware encryption).

[16:28]<kenh> Channel binding structure/constructor functions.

[16:29]<kenh> draft-williams-gssapi-channel-bindings-00.txt (not
yet published)

[16:29]<kenh> Generalizes structures from RFC2374.

[16:29]<kenh> CCM-BIND: GSS pseudo mechanism

[16:30]<kenh> stacks atop concrete mechs, like Kerberos 5.

[16:30]<kenh> draft-ietf-nfsv4-ccm-02.txt

[16:30]<kenh> Properlyu handles channel bindings proof exchanges.

[16:30]<kenh> Offering CCM signals willingness to use channel
bindings.

[16:30] peterd has left the room.

[16:31]<kenh> SASL w/Channel Bindings

[16:31]<kenh> Use SASL GSS-API spec

[16:31]<kenh> And use CCM-BIND, negotiate SASL mechs as usual.

[16:31]<kenh> SPNEGO and channel bindings: pretty much same as
SASL (minor changes to SPNEGO)

[16:32]<hartmans> How behind are we?  We should make sure we get
to discuss the charter

[16:32]<kenh> (no idea, jaltman should know)

[16:33]<kenh> In designing GSS CCM, useful concept noted: generic
stackable pseudo-mechs.

[16:33]<kenh> Interfaces needed to make this work.

[16:34] avri has left the room.

[16:34]<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.)

[16:34]<raeburn> I think we're pretty close to on schedule.

[16:35]<kenh> David Black, EMC: IPsec channel bindings can get
very "interesting", e.g. fiberchannel node names in IPsec endpoint
names.

[16:35]<hartmans> It's available in the id repository

[16:36]<hartmans> I think the SASL text is possibly weak; I don't
think the SASL community has reviewed

[16:36]<kenh> Nico: We don't care what the channel bindings are
at the IPsec layer.

[16:37]<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.

[16:37]<kenh> Second presentation by Nico: Stackable GSS
mechanisms

[16:37]<kenh> Brief history:

[16:38] Kurt has left the room.

[16:38]<kenh> 2000 - LIPKEY, basic-over-SPKM

[16:38]<jas> Re williams-gssapi-channel-bindings: Do you have a
URL? I thought it hadn't been submitted yet.

[16:38]<kenh> Early 2003: CCM-BIND (I-D), first stackable GSS
pseudo-mechanism.

[16:38]<hartmans> No, the new version hadn't been submitted

[16:39]<kenh> 58th IETF: hallway discussion of mechanism resulted
in need for abstraction.

[16:39]<hartmans> hold on

[16:39]<kenh> Glossary: Concrete mechanism - Mech that can be
used as-is.

[16:39]<kenh> Pseudo-mech: mech only useful without reference to
a concrete mech (e.g., SPNEGO)

[16:40]<hartmans> No, I'm wrong.  nfsv4-channel-bindings is what
exists of williams-channel-bindings today.

[16:40]<hartmans> Nico may have sent the other draft to the list

[16:40]<kenh> stackable pseudo-mech: mechanism that can be
stacked above or combined with a concrete mechanism.

[16:40]<kenh> Introduction:

[16:40] jjavip has entered the room.

[16:40]<kenh> GSS-API mechs exist for Kerberos 5, PKIX (SPKM),
and others such as MS NTLMSSP, Sun's mech_dh.

[16:40]<jas> Ok, thanks.

[16:41]<kenh> GSS pseudo-mechanisms exist today - SPNEGO.

[16:41]<kenh> When developing new lightweight pseudo-mech for NFS
we expanded on channel bindings and came up with CCM.

[16:42]<kenh> Composite mechs have OID, just like any other
mechanism.

[16:42]<kenh> LIPKEY: Almost a stack (does equivalant of
basic-over-SSL)

[16:42]<kenh> Other idea for stackable pseudo-mechs:

[16:43]<kenh> Proper channel binding - CCM-BIND

[16:43]<kenh> PFS, Compression, basic-over-*, three party auth.

[16:44]<kenh> Example: Perfect Forward Secrecy.

[16:44]<kenh> Context tokens might contain tokens from lower
mech, DH public parameters, and it's own per-message tokens.

[16:45]<kenh> Not all mechanism stacks make sense (e.g., pfs,
compress, krb5 is no good, but {compress, pfs, krb5} is okay.

[16:45]<kenh> Complexity - how many valid composites, how to
negotiate?

[16:45]<kenh> GSS_indicate_mechs() - don't want to make stackable
mechs available to apps.

[16:46]<kenh> Solutions:

[16:46] peterd has entered the room.

[16:46] jjavip has left the room.

[16:46] jjavip has entered the room.

[16:46]<kenh> GSS_indicate_mechs() MUST not indicate stackable
mechs and composite mechs (composite mechs okay if explicitly
configured to do so).

[16:46]<kenh> New APIs for stackable/composite mechs.

[16:47]<kenh> Composite mech users know what features they want
from them,, but why should the knnow the OID of the composite mechs?

[16:47]<kenh> Add API for inquiring mechs by attributes.

[16:47]<kenh> These new APIs are all optional.

[16:48] jis has entered the room.

[16:48]<kenh> Stackable pseudo-mechs should describe constraints
on how they can be mixed with others.

[16:48]<kenh> Benefits of new APIs:

[16:48]<kenh> No need to hardcode mechanism OIDs anymore.

[16:49]<kenh> e.g, SSHv2 MUST NOT use SPNEGO, but SPNEGO might
get new OIDs.

[16:49]<kenh> Indicating mechs by attributes makes applications
more general.

[16:49]<kenh> New APIs (see slides for details, I can't type that
fast)

[16:50]<kenh> Mechanism attributes: concrete, stackable,
composite, glue, other.

[16:50]<kenh> Depreciated (old krb5 mech OID), non-standard (GSI
SSL mech)

[16:51]<kenh> authenticates initiator, acceptor, other.

[16:51]<kenh> draft-williams-gssapi-stackable-pseudo-mechs-00.txt

[16:52]<kenh> No questions;

[16:52]<kenh> next presentation: Wyllys Ingersoll, Sun
Microsystems.

[16:52] jjavip has left the room.

[16:52] jjavip has entered the room.

[16:53]<kenh> Change of plans: discussion of C# language bindings
by J.K. of Microsoft.

[16:53]<kenh> Not able to get draft out in time.

[16:54]<kenh> First version is just a description of MS's
implementation of current GSS-API bindings.

[16:54]<kenh> We are hoping that this will be the right forum.

[16:55]<kenh> Interested in hearing from people who had
experience with Java GSSAPI bindings.

[16:55] fp has entered the room.

[16:55]<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.

[16:55]<sommerfeld> api's are hard

[16:56]<kenh> Nico: If you publish it somewhere else,
informational draft here would be nice, but have no strong opinion
either way.

[16:57]<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.

[16:57]<kenh> Now, presentation from Wyllys:

[16:58]<kenh> Original SPNEGO draft implemented early on by MS.

[16:58]<kenh> When Sun tried to implement it, discovered interop
problems with MS implementation.

[16:59]<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.

[16:59]<kenh> (Those were all spec issues)

[16:59] dinakar has entered the room.

[17:00]<kenh> Implementation issues: Kerberos OID is wrong, off
by one byte, which changes whole OID.

[17:00] Kurt has entered the room.

[17:01]<kenh> Mechlist MIC field not valid for request, and
server ignores mechlist MIC field completely.

[17:01] fp has left the room.

[17:02]<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)

[17:02]<kenh> Without using mechlist-MIC, you get SNEGO, not
SPNEGO.

[17:03]<kenh> We couldn't find a way of producing a
backwards-compatible implementation that followed the spec and
interoperated with MS.

[17:03]<hartmans> And that's "secure" single sign-on

[17:03]<warlord> "backwards compatible" with what?

[17:03]<sommerfeld> "secure" "single" "sign"-"on"

[17:03]<hartmans> Microsoft

[17:04]<kenh> One suggestion is to have a flag day among vendors,
but that won't likely work.

[17:04]<hartmans> Bill, good point.  I can think of ways in which
each of those words doesn't apply to the http negotiate mech.

[17:04]<kenh> Another suggestion is to clarify spec and get a new
OID.

[17:05]<hartmans> Even if you have a new OID, you need to have a
flag day

[17:05]<kenh> End of Wyllys's presentation, slides available
later.

[17:05]<kenh> jaltman: Proposed charter.

[17:06]<kenh> Looking at moving two directions at once:
informational draft with wisdom for gssapi v2, new draft describing
gssapi v3.

[17:08] jis has left the room.

[17:10]<kenh> Paul (?), Cisco: are we voting on this whole thing
as one basket, or on individual pieces?

[17:11]<kenh> Nico: The only thing that might break backwards
compat is the naming work (no canonical names for some mechs).

[17:11]<kenh> (just as a clarification)

[17:11] jjavip has left the room.

[17:12]<kenh> Open mike for charter items:

[17:12] peterd has left the room.

[17:12]<kenh> Joe Saloway, Cisco: W.R.T channel bindings, might
be worth investigating of we can get some commonality from SASL &
EAP.

[17:12] leg has left the room.

[17:13]<kenh> Joe: In terms of naming, might need to update
existing mechanisms to deal with new naming.

[17:13]<kenh> jaltman: agreed, naming is an open topic still.

[17:14]<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.

[17:14]<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.

[17:15]<kenh> sam: if people want to drop things, my personal
preference is to drop gssapiv2 clarifications.

[17:16]<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.

[17:17]<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.

[17:18]<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.

[17:18]<hartmans> EAP has the same chanel bindings problems even
if they don't call it channel bindings.

[17:18] dinakar has left the room.

[17:19]<kenh> Joe saloway: there are a couple of drafts that deal
with things similar to stackable mechs in EAP.

[17:19]<kenh> nico: Similar things in Kerberos with preauth
mechanisms.

[17:20] Kurt has left the room.

[17:20]<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.

[17:21]<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.

[17:22] admcd has entered the room.

[17:22]<kenh> answer to jas's question (from jaltman): I do not
believe we're discussing any new APIs.

[17:22]<kenh> Nico: We're just talking about changes in semantics.

[17:23]<kenh> Nico: But some list members believe that's
effectively a new API.

[17:24]<kenh> Nico: The big issue is that if you write a threaded
GSSAPI program, you lose portability.

[17:25]<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".

[17:25]<kenh> jaltman: Idea is similar to Kerberos
clarifications: explanations of what apps might expect, and what we
thought the spec meant.

[17:26]<jas> fwiw, changing semantics to make threaded use work
would be fine by me, but introducing new APIs for threading seem
convoluted.

[17:26]<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.

[17:26] rlbob has left the room.

[17:27]<kenh> jas: Everyone agrees with you, and we are not
proposing creating new APIs for that purpose.

[17:28]<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.

[17:29] admcd has left the room.

[17:29] raeburn has left the room.

[17:29]<kenh> Russ: Question asked: Do people think that this
belongs in the IETF?  Looks like the consensus is that the answer is
"yes".

[17:29] tlyu has left the room.

[17:29] hartmans has left the room.

[17:29] kenh has left the room.

[17:30] dumdidum has left the room.

[17:30] pbh has left the room.

[17:31] warlord has left the room.