IETF
kitten
kitten@jabber.ietf.org
Thursday, 28 July 2011< ^ >
stpeter has set the subject to: KITTEN WG | http://tools.ietf.org/wg/kitten/
Room Configuration

GMT+0
[21:33:31] jimsch joins the room
[21:41:11] ghudson@mit.edu/barnowl joins the room
[21:41:58] tlyu joins the room
[21:42:00] <jimsch> Meeting starts
[21:42:28] <jimsch> Starting Pleminaries
[21:44:07] nico joins the room
[21:44:08] nico leaves the room
[21:44:15] nico joins the room
[21:44:15] nico leaves the room
[21:44:21] hartmans joins the room
[21:44:21] nico joins the room
[21:44:22] nico leaves the room
[21:44:23] nico joins the room
[21:44:23] nico leaves the room
[21:44:25] nico joins the room
[21:44:25] nico leaves the room
[21:45:14] <jimsch> Agenda Basing -
[21:45:31] <jimsch> Active WG Item Review
[21:45:42] <jimsch> gssapi-extensions-iana slide
[21:46:37] <jimsch> Need help to finish the registry changes - please see Shawn if interested
[21:46:49] <jimsch> slide - digest-to-historic - now an RC
[21:46:55] <jimsch> slide - gssapi-naming-exts
[21:48:13] <jimsch> sam: last state - revised the doucment.
[21:48:51] <jimsch> sam: what happens if you set an attribute the mechinsim has not heard of - still an open issue
[21:48:53] nico joins the room
[21:48:53] nico leaves the room
[21:49:35] <jimsch> sam: how do you figure it out? Currently implemenations return error if set a name they have never heard of
[21:50:13] <jimsch> sam: several proposals were proposed
[21:50:31] <jimsch> sam: cannot remember finalization of discussion or if the document reflects that concensus
[21:51:21] <jimsch> sam: ACTION REQUEST - chairs please review list and see if concensus was reached and if document has been updated
[21:52:09] <jimsch> sam: want to spend a single day on this item -no rat hole discussion on what "don't understand" means
[21:52:13] <jimsch> Comments?
[21:52:25] <jimsch> slide - sasl-openid drafts
[21:52:57] <jimsch> SF: - lots of minor comments
[21:53:25] <jimsch> SF: open id connect? - can't remember details -
[21:53:37] <jimsch> SF: has spoken to Elliot
[21:53:43] nico joins the room
[21:53:47] tlyu leaves the room
[21:53:53] tlyu joins the room
[21:53:58] <nico> alright, made it
[21:54:07] <jimsch> Hannas - discussion w/ others - don't think it makes any necessary changes
[21:54:23] <jimsch> slide - sasl-saml draft
[21:54:47] <jimsch> authors believe it is ready
[21:54:48] SFTCD joins the room
[21:54:55] <jimsch> should go out soon
[21:55:05] <jimsch> slide - sasl-saml-ec draft
[21:55:23] <jimsch> slide - sasl-oauth
[21:55:25] Satoru Kanno joins the room
[21:56:29] <jimsch> Talk Exporting Parital Security Contexts
[21:57:11] <jimsch> Talk - Replay cach avoidence instead
[21:57:23] <jimsch> slide - Replay cacheing is a pain
[21:57:41] <nico> it's one PDF has both
[21:57:45] <nico> rcache first
[21:57:47] <nico> ;)
[21:58:00] <nico> looking for webex/audio info
[21:58:31] <tlyu> http://ietf81streaming.dnsalias.net/ietf/ietf807.m3u
[21:58:47] <jimsch> slide - fast replay caching (1)
[21:58:47] <nico> danke
[21:59:15] <jimsch> slide - fast replay caching (2)
[21:59:42] <nico> I didn't think I'd make it
[22:00:13] <jimsch> slide - replay cache avoidance (1)
[22:00:36] <nico> thanks for presenting this Shawn!
[22:00:41] <nico> I really apprciate it
[22:00:50] <nico> sry i couldn't be there :(
[22:01:47] <nico> can't hear Sam
[22:01:51] <nico> better
[22:02:45] <jimsch> sam: if you use freshness in message or in the channel binding then the cache is not necessary
[22:02:49] <nico> Sam: never mind channel binding here
[22:03:30] <nico> yes, we need a flag to do two things: 1) to tell the server we're doing this, 2) to ensure that the AP-REQ is not accepted in some other context if cut-n-pasted
[22:04:10] <jimsch> sam: WHy we care about the cut-n-paste?
[22:04:19] <nico> because we might not have a channel
[22:04:45] <nico> think of rsh
[22:04:53] <ghudson@mit.edu/barnowl> If you don't insert the authenticator into the replay cache, it could
be replayed to a different protocol which doesn't have the nice
properties.
[22:04:58] <nico> riiight
[22:05:01] <ghudson@mit.edu/barnowl> Even if the other protocol implementation uses a replay cache.
[22:05:08] <nico> you got it
[22:05:23] <nico> :-]
[22:05:45] <jimsch> slide - Replay Cache avoidance (2)
[22:06:22] <nico> same issue
[22:06:22] <hartmans> My brain is fried at this point in the week.
[22:06:48] <nico> hartmans: no problem :) you might remember this issue from SSHv2 + GSS...
[22:07:13] <jimsch> sam: THis is sounding very kbr specific - comments/
[22:07:27] <nico> yes, this is more for Kerberos than for KITTEN
[22:07:34] <nico> there's some GSS impact
[22:07:40] <nico> new req_flag and all
[22:07:53] <nico> the fast replay cache stuff is relevant to all sorts of things
[22:08:16] <nico> but you should wait for the next slides
[22:08:24] tlyu leaves the room
[22:08:27] <hartmans> I agree that the gss flags and stuff are general
[22:08:30] tlyu joins the room
[22:08:41] <jimsch> slide - Replay Cache Avoidance (2) - other uses
[22:09:05] <nico> oh, well, this slide is more Kerberos-specific
[22:09:40] <nico> I really want the mech to support u2u
[22:10:21] <nico> :)
[22:10:28] <jimsch> slide - Replay caching for clusters
[22:11:07] <jimsch> slide - consensus questions
[22:11:24] <nico> "clusters make rcache hard", painful, really
[22:12:08] <nico> so do we want to pursue any of this, and if so, where?
[22:12:10] <jimsch> which solution of the three should be used?
[22:12:14] <nico> what and where
[22:12:29] <jimsch> sam: what if we want multiple solutions?
[22:12:31] <nico> what's the question, again?
[22:12:40] <jimsch> still in argument
[22:12:42] <nico> jimsch: thx
[22:13:11] <jimsch> sam: Implied leg required - explicit would be nice for people who implement
[22:13:24] <nico> yes, I agree, implied 3rd is best, and we ought to always make app protocols make implied 3rd leg suffice
[22:13:27] <jimsch> sam: no interop problems because two different poeple are using idfferent solutions
[22:13:39] <nico> the initiator chooses which, if we spec both
[22:13:45] <ghudson@mit.edu/barnowl> I'm a little confused on how you negotiate explicit third-leg given
that authenticators using it have to be unacceptable to old software.
[22:13:52] <hartmans> O, so you'd rather not do explicit third?
[22:13:55] <hartmans> I can live with that too.
[22:14:01] <nico> ghudson: AP-REP extension
[22:14:23] <nico> hartmans: yes, I think I prefer implied 3rd leg
[22:14:34] <jimsch> sam: to greg - new OID
[22:14:41] <nico> no new OID!!!
[22:14:59] <nico> Sam needs the mic with him
[22:15:07] <jimsch> tom - maybe need more study?
[22:15:08] <nico> no, not that I don't like it, we don't need it!!
[22:15:13] <nico> this works without a new OID
[22:15:13] <ghudson@mit.edu/barnowl> I'm fine with going in the implied third leg direction, so the
question about explicit third leg may be moot.
[22:15:24] <jimsch> sam: is there anyone who does not want to do implicit third leg?
[22:15:32] <jimsch> sam: If never get beyond that point should be fine
[22:15:36] <nico> good point
[22:15:51] <hartmans> nico: how else do you negotiate explicit third vs old style?
[22:15:52] <jimsch> shawn: Who does not think that implicit 3rd leg is a possible solution?
[22:15:58] <nico> also, we still need fast rcache for any apps that use PROT_READY -- or we could deprecate PROT_READY
[22:16:19] <hartmans> nico: or deprecate replay_det for prot_ready
[22:16:26] <nico> hartmans, ghudson: AP-REQ has flag requesting explicit 3rd leg, old server sends old AP-REP, new server sends *new* AP-REP
[22:16:37] <nico> hartmans: oh, good point!
[22:16:43] <hartmans> or just not set replay_det for prot_ready
[22:16:50] <jimsch> Rephrase question:
[22:17:19] <jimsch> Shawn: Implied third leg should be a solution - show hands
[22:17:22] <ghudson@mit.edu/barnowl> +1 on implied third leg
[22:17:23] <nico> you can't not set replay_det for prot_ready -- this is on the peer side
[22:17:38] <jimsch> nico?
[22:17:42] <nico> +1
[22:17:48] <nico> +1 on implied 3rd leg, that is
[22:18:01] tlyu leaves the room
[22:18:07] tlyu joins the room
[22:18:09] <nico> (this might mean I need not finish my fast rcache code! :) :)
[22:18:12] <jimsch> shawn: Who does not think that implied 3rd leg is a solution?
[22:18:28] <nico> wish Martin was here!
[22:18:38] <jimsch> CONCENSUS - Yes it is a solution
[22:19:04] <hartmans> nico: you can fail to set the flag for whether the service is available.
[22:19:04] <jimsch> Shawn: Who would like the explicit 3rd leg as a soution?
[22:19:34] <jimsch> nico? greg?
[22:19:35] <nico> I'd work on it, if we agreed that we need it
[22:19:44] <nico> but I could live with implied 3rd leg only
[22:19:47] <ghudson@mit.edu/barnowl> No opinion one way or another for explicit third.
[22:19:49] <hartmans> I.E. we can say that 4121 mechanisms must not set replay detection as an available service until context is fully established.
[22:20:06] <jimsch> Tom: WHo thinks we should not do the explicit 3rd leg option?
[22:20:26] <jimsch> no votes either wayl
[22:20:35] <nico> hartmans: the PROT_READY token will not be processed until the context is complete
[22:20:52] <nico> alright, so no explicit 3rd leg then
[22:20:55] <jimsch> slide - Exporting Paritally- Established GSS security contexts (1)
[22:21:06] <nico> question: are there GSS mechs for which we might want it?
[22:21:30] <tlyu> nico: "it" = ?
[22:21:55] <nico> tlyu: "it" == explicit 3rd leg. I.e., do we want to spec the req_flag for it
[22:22:10] <jimsch> slide - Contexts(2)
[22:22:46] <nico> ok, thanks!
[22:23:02] <jimsch> sam: Is there any harm in delaying the flag until somebody explicitly says they want it?
[22:23:06] <nico> no harm, no
[22:23:33] <nico> agreed
[22:24:36] <nico> Sam had suggested that for state cookies we might want a generic utility function, to make app devs' lives easier, and I agree
[22:25:34] <jimsch> sam: would probably be done in the ietf
[22:26:44] <jimsch> sam: Have sym key - take exported context - encrypt it - associated data and make it a utilty function in the glue layer so that nobody needs to repeat creating the code
[22:26:58] <nico> suggested consensus questions: do we want to do partially established sec context export? and if so do we want to do encrypted state cookie utilities (export-and-encrypt, decrypt-and-import)
[22:27:02] <ghudson@mit.edu/barnowl> So you have to pass a key to this utility function?
[22:27:34] <jimsch> sam: you may need to have mechinism attributes - i.e. re-use of counters for counter mode ciphers -
[22:27:34] <nico> ghudson: probably not, no -- either the caller has access to the key, or not, with the key stored 0600 somewhere where if the app re-starts you could find it
[22:27:42] <jimsch> sam: I think it is the case that you can only hurt yourself
[22:28:17] <nico> no re-use counters -- no replay detection with this unless we slap on a replay cache -- we want that as a flag on the export-and-encrypt and an output flag on decrypt-and-import
[22:28:22] <jimsch> sam: An attacker outside of the conversation would not have and advantage - but we need to do a check on this to make sure it is true
[22:28:42] <ghudson@mit.edu/barnowl> nico: I'm thinking about cases where a different KDC imports the
context than exported it.
[22:29:00] <jimsch> sam: Define a new mechismism attribute "replay my context" and query for it before generating the cookie.
[22:29:04] <nico> ghudson: yes, same answer
[22:29:27] <jimsch> sam: glue - just have an export, import and pass some flagus such as replay question
[22:29:59] <jimsch> sam: yes store key in the glue - maybe pass in a key name
[22:30:47] <nico> ah, we probably want a cluster flag too!
[22:30:50] <jimsch> sam: Hope we don't need a replay cache for first version - would need to look at the cache being a cluster
[22:30:59] <nico> (so we can return an error if there's no cluster rcache support)
[22:31:09] <nico> yeah, so don't use counter mode here!!
[22:31:18] <ghudson@mit.edu/barnowl> I'm still confused about this encryption key. Does the mechglue make
it up? If I were using this on a KDC, I'd want to use a key shared
between the KDCs.
[22:31:22] <jimsch> sam: I am fine if you kill yourself - just not others
[22:31:48] <nico> ghudson: the admin does, and puts it where the mechglue expects it, or else the mechglue gens it and the admin syncs it on clusters
[22:31:48] <jimsch> sam: yes - use a shared key between KDCs -
[22:32:04] <nico> yes, the cookie wants a key _name_
[22:32:22] tlyu leaves the room
[22:32:28] tlyu joins the room
[22:32:30] <nico> not true!
[22:32:33] <nico> GSS pre-auth!
[22:32:35] <nico> ;)
[22:32:46] <nico> (isn't Alex in the room?)
[22:33:00] <jimsch> No he is in a different meeting
[22:33:00] <nico> SamL please, use imagination
[22:33:19] <nico> I'm saying this key sharing issue is an implementation issue, not one we should care about
[22:33:27] <nico> s/SamL/Sam:/
[22:33:36] <jimsch> tom: do we want to standardize the context - what aoubt versioning if it is mech sepecifc
[22:33:44] <jimsch> sam: leave up to mech
[22:34:02] <jimsch> SHAWN: Who thinks this is an issue that they want to solve?
[22:34:14] <jimsch> nico?
[22:34:22] <nico> I do!
[22:34:44] <nico> I think we should at least allow gss_export/import_sec_context() to do partial sec contexts
[22:34:44] <jimsch> SHAWN: Should we create a utility function to export parital security contexts?
[22:34:55] <nico> I think we should spec a utility function
[22:35:03] <nico> because we need to make this easy and safe to use
[22:35:15] <hartmans> nico: I think the implementation issues are important for this API sort of.
[22:35:19] <nico> else it will be misused, and that'll be bad
[22:35:25] <hartmans> Especially if you want an abstraction between the mechglue and the kdc.
[22:35:29] <jimsch> (7)
[22:35:34] <hartmans> Which I think you want because the kdc is massively non-unique.
[22:35:37] <nico> hartmans: yes, but we *can* solve them and they are not relevant to KITTEN itself
[22:35:44] <hartmans> For example a distributed RADIUS server would want exactly the same thing probably.
[22:36:02] <jimsch> CONCENSUS - Get a design team to geyther to hash out the interface and define the token format
[22:36:08] <hartmans> nico: I think they do matter for the interface.
[22:36:09] <jimsch> Call for volunteers
[22:36:11] <nico> yes, so maybe we don't want the mechglue doing this, but the mech provider (because mech_krb5 could know to look in the keytab/KDB for the key)
[22:36:26] <jimsch> nico?
[22:36:28] <jimsch> greg?
[22:36:32] <nico> hartmans: I think we don't want anything more than a key name in the API
[22:36:35] nico raises hand
[22:36:36] <hartmans> I think I've been convinced that Greg is right and you need to be able to pass in a key
[22:36:40] <ghudson@mit.edu/barnowl> I can.
[22:37:09] <nico> hartmans: configuration is not a problem, also, this could be yet another use case for the PGSS discussion
[22:37:10] <jimsch> VOLUNTEERS: Sam, Nico, ghudson
[22:37:13] <ghudson@mit.edu/barnowl> This is sort of interesting because GSSAPI doesn't currently traffic
in keys.
[22:37:26] <jimsch> Next presentation - GSS-APIv2u1 issues
[22:37:28] <nico> ghudson: yes, but I'd just use a name, not a key
[22:37:29] <hartmans> greg: agreed.
[22:37:34] <jimsch> slide #1
[22:37:35] <nico> C bindings issues
[22:37:39] <hartmans> I'd like to convince myself that Nico is right and that all you want is a key name
[22:37:41] <nico> not abstract API issues
[22:38:05] <nico> hartmans: I don't mind an option to specify the key, but I want it to be optional
[22:38:09] <jimsch> slide - memory management hell
[22:38:19] <hartmans> nico: definitely optional.
[22:38:41] <nico> hartmans: good, so we agree
[22:39:13] <jimsch> slide - Minor Status Issues
[22:39:50] scottcantor joins the room
[22:40:47] <jimsch> slide - Extensibility/Layering issues
[22:41:20] <nico> two apps in same process
[22:41:43] <jimsch> slide - Extensibilty/Layering issues (2)
[22:42:30] <nico> not flag, return value
[22:42:32] <nico> GSS_S_...
[22:42:47] <jimsch> slide - Solutions?
[22:43:45] <jimsch> tom: change header file - change the C type in the header file
[22:43:50] <nico> yes, thanks Tom
[22:44:21] <jimsch> slide - PGSS-API
[22:45:14] <nico> yes, opaque
[22:45:45] <jimsch> slide - GSS-APIv3
[22:47:32] <nico> hartmans: if the app gets no value, then what's the point?
[22:47:33] <jimsch> sam: I am not an app developer - I do mechs - I think there is value even if the mechs change and the apps don't - if you can improve the SPI between the glue and the mechs then there is value even if you don't have it for the apps until later
[22:47:45] <jimsch> sam: Need all mechs to change however
[22:48:07] <ghudson@mit.edu/barnowl> Perhaps applications aren't motivated to change, but library users are
(for better isolation between themselves and apps).
[22:48:21] <jimsch> sam: for memory allocation issue if glue/mech is cleaned up then easier to clean leaks?
[22:48:27] <nico> no!
v3 SPI does not solve mem mgmt
[22:48:57] <nico> v3 API + v3 API does solve mem mgmt
[22:49:08] <nico> oh
[22:49:09] <nico> right
[22:49:11] <nico> sorry
[22:49:15] <nico> yes, I forgot
[22:49:20] <nico> maybe I'm fried too...
[22:49:36] <nico> basically, a v3 SPI would allow the mechglue to tell the providers what allocator to use
[22:49:41] <nico> however
[22:50:03] <nico> I also had in mind crypto HW where the memory must be allowcated from a driver, not a normal allocator
[22:50:19] <nico> I wonder what the latency is
[22:50:24] <ghudson@mit.edu/barnowl> Can't a mechglue, today, just copy the mech's result buffer so it
knows all caller-visible buffers are allocated by the mechglue?
[22:50:26] <nico> it seems like "a lot"
[22:50:39] <nico> ghudson: memory copies kill performance
[22:50:52] <ghudson@mit.edu/barnowl> I feel like we already kill performance past that point, but let's
move on.
[22:50:55] <jimsch> slide - Real-Time linker fun (1)
[22:50:57] <nico> (sure, not for SSHv2 w/ GSS, but for NFSv4?!)
[22:51:32] STFU joins the room
[22:51:53] <jimsch> slide - Linker Fun(2)
[22:52:26] <jimsch> slide - Linker Fun(3)
[22:52:37] <nico> oh, hmmm, my code snippets aren't right
[22:52:42] <nico> but you get the idea
[22:52:54] <nico> 'twas late when I wrote them :/
[22:53:07] <jimsch> slide - Linker Func(4)
[22:53:29] tlyu leaves the room
[22:53:31] <jimsch> slide - Questions
[22:53:35] tlyu joins the room
[22:54:27] <nico> BTW, I didn't mean to speak for Margaret nor Sam, but I didn't know if they'd be in the room when I wrote this
[22:54:47] <nico> so I wanted to give the audience an idea of the opinions I've managed to elicit to date
[22:55:06] <jimsch> sam: If we aqre going to do work - please have somebody say there is a problem that I have today
[22:55:13] <jimsch> sam; want current use cases of problems
[22:55:33] <jimsch> sam: As a mech imploementer the memory manange problems are killing me
[22:55:58] <nico> heh
[22:56:01] <jimsch> sam: Other use case that is problematic is needing more extensibilty for acquire creds
[22:56:37] <jimsch> Any other app developers want to give problems?
[22:57:07] <nico> I could use GSS initial cred acquisition, so, yes
[22:57:07] <jimsch> tom (self): Kbr consorition has heard from sponsors - might have programs in a single process to handle different sets of configureaqtion
[22:57:39] <jimsch> tom - can only do this by chaning env varaibles or files in the file sysstem - in a single process this would need a new context handle to pass in - would be useful
[22:57:55] <nico> also, I have other use cases, some which I may need to implement later this year, in particular dealing with multiple providers for the same mechanism
[22:57:57] <jimsch> sam: are you willing to re-write code?
[22:58:11] <jimsch> tom: yes - if high confidence a good solution not horible to implement
[22:58:29] <nico> I will likely write a GSS proxy library, and I'd like the mechglue to be able to use that and a regular provider for the same mechs
[22:58:59] <ghudson@mit.edu/barnowl> I think I might be willing to write mechglue and krb5 mech code for
gss3 if there were a standard behind it.
[22:59:21] <jimsch> sam: styleistic question - lots of types and functions or not - perfer lots of apis with with small patermeters -\
[22:59:28] <nico> ghudson: most of the mechglue can be generated from a gss function description model and a compiler for it
[22:59:31] <jimsch> sam: use an object to pass in options
[22:59:48] <nico> yes, I do dislike that pattern
[23:00:09] <jimsch> sam: easier to decide what to do if we have a style to choose from now
[23:00:19] <jimsch> sam: if dopn't use that design pattern then far from solution
[23:00:57] <jimsch> sam: If gss-api v3 rewrite - then will have a sam/nico arguemnt about how it should be done
[23:01:21] <nico> note that we could look at other successful APIs for ideas
[23:01:35] <nico> also, we could ask various people who've voiced opinions in the past in this area
[23:01:52] <nico> I abhor this museum of v2u1 APIs that we're building
[23:01:59] <jimsch> sam: Need to have the sytle decision before knowing which otion to support
[23:02:04] <ghudson@mit.edu/barnowl> I am not able to connect the dots between options objects and not
needing a gss3.
[23:03:11] <jimsch> sam: we might have almost enough option objects not to need a gss3
[23:03:39] <jimsch> sam: need to propose some extensions that are not in the gss3 timeframe and need to know what style to use for that
[23:03:59] <jimsch> sam: don't know if the right people and enough thought at ths point on the decision
[23:04:57] <jimsch> tom: Who thinks tha tth ememory managment problem needs fixed?
[23:04:59] <nico> I must go soon
[23:05:06] nico raises hand
[23:05:21] <jimsch> 5 to 0
[23:05:39] <ghudson@mit.edu/barnowl> Sam: no, you just need copies.
[23:05:40] <jimsch> sam: cannot currently do it on windows w/o this
[23:05:46] <nico> yeah, we're already requiring one mem allocator :)
[23:06:55] <hartmans> I think I could agree that we should not do ad-hoc things.
[23:07:06] <hartmans> The question though in my mind is more types good more types bad
[23:07:10] <nico> what I don't like is adding more and more functions to replace existing ones + with new "options" structures/types
[23:07:21] <nico> I don't think we'll settle the style issue here
[23:07:38] <hartmans> Where as I think that's a good design pattern for evolving an API
[23:07:45] <nico> we should close shop for the day and fight this out on the list :)
[23:07:50] <nico> but also, I need dinner
[23:08:00] <nico> and my dinner mates await!
[23:08:01] <hartmans> If we can't settle that style question how do we move forward?
[23:08:02] <nico> ;)
[23:08:19] <nico> hartmans: I meant "here" as in "right now"
[23:08:31] <hartmans> ah, ok
[23:08:38] <nico> because I'd have said "here" if I'd been physically in the room, in Quebec
[23:08:49] <nico> clearly if we can't settle this at all that's bad
[23:08:59] <nico> but this isn't the debt ceiling debate anyways
[23:09:04] <jimsch> New topic - Recharter Discussion
[23:09:10] <nico> thanks all
[23:09:12] <nico> I'm off
[23:09:18] <jimsch> ta
[23:10:06] <jimsch> volunteers for author/revieers of replay cache avoidance
[23:10:08] <nico> thanks jimsch so much for scribing, and semery for presenting my presentations
[23:10:18] <jimsch> hannes says will review
[23:10:19] <nico> I volunteer for the rcache avoidance bits
[23:10:26] <jimsch> leif can review
[23:10:28] <nico> spec and implement
[23:11:32] <jimsch> slide - review and milestones
[23:11:38] <jimsch> shawn: ok we are going to skip this
[23:11:43] <jimsch> OPEN MIKE
[23:12:54] <jimsch> hannes - for sasl-oauth - new version contains text on channel binding - also include text for mech identification - need to changes references
[23:13:10] <jimsch> - will ship update for editoral and context updates -
[23:13:14] <jimsch> = also have exmaples
[23:13:48] <jimsch> = oauth group has made progress - but documents are not yet publsuehd so have normative dependency and may have changes over there
[23:16:22] <jimsch> = discussion on document dealing iwht oauth and transport seucrity - document link may follow
[23:16:44] <STFU> draft-balfanz-tls-obc-00
[23:17:04] <STFU> TLS Origin-Bound Certificates
[23:17:06] <jimsch> needs to have a channel binding review
[23:17:45] SFTCD leaves the room
[23:17:45] <jimsch> Meeting closed
[23:17:54] jimsch leaves the room
[23:18:09] tlyu leaves the room
[23:18:20] Satoru Kanno leaves the room
[23:18:33] scottcantor leaves the room
[23:21:50] STFU leaves the room
[23:34:06] hartmans leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!