[08:39:45] --- pigdog has joined
[08:51:10] --- ryu.inada has joined
[08:51:52] --- tlyu has joined
[08:58:57] --- agallant has joined
[09:00:10] --- cat has joined
[09:00:19] --- marcos.sanz has joined
[09:00:31] --- kdz has joined
[09:00:39] --- Lisa has joined
[09:00:43] --- raeburn has joined
[09:00:59] --- ben has joined
[09:01:19] --- rlbob has joined
[09:01:24] <marcos.sanz> We are about to start
[09:01:33] <marcos.sanz> I am the jabber scribe
[09:01:36] --- kurosaki has joined
[09:01:47] <marcos.sanz> For questions or issues to the microphone, please indicate with a starting "mic:"
[09:01:55] <pigdog> thank you marcos for scribing!!!
[09:02:00] <marcos.sanz> Agenda under http://www3.ietf.org/proceedings/06jul/agenda/wae.txt
[09:02:13] --- Ted has joined
[09:02:18] --- mnot has joined
[09:02:34] <cat> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66#wg-wae
[09:02:35] <kdz> main presentation: http://www3.ietf.org/proceedings/06jul/slides/wae-0.ppt
[09:02:44] --- hartmans has joined
[09:03:04] --- Melinda has joined
[09:03:28] <marcos.sanz> Administrivia: scribes, blue sheets
[09:03:52] --- dblacka has joined
[09:04:05] --- dumdidum has joined
[09:04:17] <marcos.sanz> Pete: People not to queue at the mics, just pass them around. The cords are long.
[09:05:03] <marcos.sanz> Pete: 10 minutes must be spent in terminology, because ppl have a very differnet vocabulary
[09:05:33] <marcos.sanz> Then 55 mins for identifying problems
[09:05:39] --- Jeffrey Altman has joined
[09:05:43] --- miaofy has joined
[09:05:54] <ben> I would contend that we will not solve in 10 minutes what has been argued about for the last year or more on various lists
[09:06:10] <Lisa> We're not going to solve, just declare a temporary truce and situation.
[09:06:24] <ben> ok :-)
[09:06:36] <Jeffrey Altman> we will start shooting from ten paces and the last man standing wins ....
[09:06:44] <Ted> That's sexist.
[09:06:45] <cat> ... about those orbital rail guns ...
[09:06:46] <marcos.sanz> Then 55 miins on mechanisms to use
[09:06:52] <Ted> Lisa's a pretty fast draw
[09:07:00] <cat> Ted - sure :) It means that Lisa and I can stand back and watch...
[09:07:03] <ben> then she'll be the last man standing
[09:07:04] <marcos.sanz> And then half an hour to identify work items, documents, editors
[09:07:12] <Jeffrey Altman> then the last man standing may very well be a woman !!!!
[09:07:21] --- Jerry Shih has joined
[09:07:24] --- jhutz has joined
[09:07:37] <raeburn> Ooh, paper. How quaint. :-)
[09:07:43] <marcos.sanz> Starting with terminology:
[09:07:58] <Jeffrey Altman> can someone put up a web cam focused on the paper?
[09:08:21] <marcos.sanz> Reading assignment: RFC 2828
[09:08:23] <jhutz> oh, clever idea
[09:08:28] --- washad has joined
[09:08:31] --- dblacka has left
[09:08:53] --- fparent@jabber.org has joined
[09:09:10] <Lisa> http://www.ietf.org/internet-drafts/draft-shirey-secgloss-v2-04.txt ?
[09:09:20] --- psangster has joined
[09:09:21] --- geoff has joined
[09:09:39] --- briansmith has joined
[09:09:40] <Jeffrey Altman> confirmed
[09:09:42] <jhutz> That's the document
[09:09:51] <marcos.sanz> That document is the long version of 2828
[09:10:15] --- tlr has joined
[09:10:40] <pigdog> jeff who?
[09:10:41] <marcos.sanz> Pete to reuse as much terminology as possible and only introduce new terms inthe IETF when necessary
[09:10:45] <rlbob> http://identitygang.org/Lexicon is the lexicon I was referring to
[09:10:56] <jhutz> That document is the _new_ version of 2828. It's fairly close to being published. The author and RFC-Editor have been kind enough to first run it past the security area directorate, which has been reviewing it for a few weeks.
[09:11:01] <Jeffrey Altman> ekr moves the mic stand
[09:11:26] <Ted> ekr flobnozzles
[09:11:30] <jhutz> jiggety
[09:11:35] <marcos.sanz> Difficult to understand ekr, sorry
[09:11:37] <jhutz> s/j/g
[09:11:42] <Jeffrey Altman> can we have a back channel for the back channel?
[09:11:45] <ben> he's a hoopy frood
[09:11:47] <jhutz> It's always difficult to understand ekr.
[09:11:59] <Ted> marcos: he said that you can attempt to create new terms
[09:12:11] <Ted> and define them. "flobnozzle" was the joke new term
[09:12:14] <marcos.sanz> Pete: Identity is the most problematic term
[09:12:22] <jhutz> What he said is that often you have the issue that no one likes each others' terminology, so you end up either redefining other people's terms in terms of your own, or you make up new terms.
[09:12:33] <Lisa> We need a terminology truce, yes.
[09:12:40] --- cullenfluffyjennings@gmail.com has joined
[09:12:40] <hartmans> I think describing it as a new version of 2828 is misleading. 2828 is an ietf document; the new one is not.
[09:12:42] <marcos.sanz> Pete philosophic about the term "Identity"
[09:13:05] <Lisa> thx
[09:13:08] <Ted> rlbob thwacks pete
[09:13:17] <Ted> pete apologizes
[09:13:23] <jhutz> was 2828 an ietf document?
[09:13:54] <marcos.sanz> Identity is not the identifier, but the thing to be identified
[09:13:55] <Jeffrey Altman> "Internet Security Glossary" http://www.ietf.org/rfc/rfc2828.txt
[09:13:55] <jhutz> The new one is certainly an updated and expanded glossary, but it is indeed not an IETF document.
[09:14:21] <Jeffrey Altman> RFC 2828 does not define "identity"
[09:14:23] <marcos.sanz> Now about "Authentication"
[09:14:33] <marcos.sanz> The 2828 definition of Authentication not very appropriate for this context
[09:14:57] <marcos.sanz> Ted reads the definition from the Shirey draft
[09:15:31] --- dblacka has joined
[09:15:58] <Jeffrey Altman> From secgloss-04: $ authenticate (I) Verify (i.e., establish the truth of) an attribute value claimed by or for a system entity or system resource. (See: authentication, validate vs. verify, "relationship between data integrity service and authentication services" under "data integrity service".) Deprecated Usage: In general English usage, this term is used with the meaning "to prove genuine" (e.g., an art expert authenticates a Michelangelo painting); but ISDs should restrict usage as follows: - ISDs SHOULD NOT use this term to refer to proving or checking that data has not been changed, destroyed or lost in an unauthorized or accidental manner. Instead use "verify". - ISDs SHOULD NOT use this term to refer to proving the truth or accuracy of a fact or value such as a digital signature. Instead, use "verify". - ISDs SHOULD NOT use this term to refer to establishing the soundness or correctness of a construct, such as a digital certificate. Instead, use "validate". $ authentication (I) The process of verifying a claim that a system entity or system resource has a certain attribute value. (See: attribute, authenticate, authentication exchange, authentication information, credential, data origin authentication, peer entity authentication, "relationship between data integrity service and authentication services" under "data integrity service", simple authentication, strong authentication, verification, X.509.) Tutorial: Security services frequently depend on authentication of the identity of users, but authentication may involve any type of attribute that is recognized by a system. A claim may be made by a subject about itself (e.g., at login, a user typically asserts its identity) or a claim may be made on behalf of a subject or object by some other system entity (e.g., a user may claim that a data object originates from a specific source, or that a data object is classified at a specific security level). An authentication process consists of two basic steps: - Identification step: Presenting the claimed attribute value (e.g., a user identifier) to the authentication subsystem. - Verification step: Presenting or generating authentication information (e.g., a value signed with a private key) that acts as evidence to prove the binding between the attribute and that for which it is claimed. (See: verification.)
[09:16:05] --- leslie@ecotroph.net has joined
[09:16:32] <pigdog> i'm very nervous that if we go through this tutorial we're never going to get to the meat of what existing problems we want to solve
[09:16:46] <marcos.sanz> Pete writes: Authentication, B verifies something about A
[09:16:51] <Ted> I share pigdog's concern
[09:17:00] <tlr> +1
[09:17:12] <cat> Well - if we don't start from some common point, there's no way that we'll have a useful conversation.
[09:17:44] <Lisa> We had terminology problems buried under some of the disagreements during DIX.
[09:17:58] --- roy has joined
[09:18:01] <marcos.sanz> Now to Authorization
[09:18:17] <marcos.sanz> Act of being granted to some resources
[09:18:28] <ben> granted access to some resources or services
[09:18:31] <marcos.sanz> "Credential"
[09:18:33] <Ted> cat: yes, but agreeing on the shirey gloss and having people check their laptops would do it. Sure, they would disagree with some of the wording, but we'd have a base set
[09:18:49] <cat> Ted - there's something to be said for having a handy one-liner.
[09:19:17] --- nico has joined
[09:19:54] --- roy has left
[09:20:03] <pigdog> i believe i have FrobNozzle trademarked, i'm sorry.
[09:20:16] <marcos.sanz> Ekr complains about bogus terminology
[09:20:30] <pigdog> when in montreal speak french?
[09:20:39] <nico> heh
[09:20:42] <Ted> pigdog: but his is flobnozzle, which is clearly different
[09:20:49] <pigdog> ;-)
[09:20:50] --- bhoeneis has joined
[09:20:53] <pigdog> who is speaking?
[09:20:59] <cat> Jeff Hodges ?
[09:21:00] <Jeffrey Altman> why is phb holding a rat?
[09:21:02] <nico> jeff hodges
[09:21:03] <Ted> Oh, look phb has brought his rat
[09:21:13] <Ted> (because this is a rat hole)
[09:21:21] <pigdog> lol
[09:21:31] <mnot> it's not fresh, tho. I was kinda hungry...
[09:22:16] <marcos.sanz> Alternative proposition: List the concepts and find agreement on a word, and not the other way round
[09:22:27] <pigdog> jhultz: *bingo*!
[09:22:47] <cullenfluffyjennings@gmail.com> There are moments where I really want streaming video
[09:22:53] <cat> No, no you don't.
[09:22:54] <marcos.sanz> phb is at the mic with a rat in his hand
[09:23:12] <pigdog> i especially don't need to see phb with a rat
[09:23:26] <jhutz> Hm; phb not reading.
[09:23:37] <marcos.sanz> sam: the trouble are the preconceived notions on some terms
[09:23:42] <jhutz> The problem is _exactly_ that phb, and everyone else in the room, already know what authentication is. But we don't all agree.
[09:23:44] --- ekr has joined
[09:23:58] <rlbob> words are defined to solve problems, it's the problems that are important, and typically a problem needs a description that is much longer than a definition
[09:24:03] <cat> I think we should try playing along for now, rather than arguing first.
[09:24:14] <jhutz> I thought phb said he was channeling ekr, but that makes no sense.
[09:24:20] <ekr> This is why I made all these ridiculous acronyms.
[09:24:22] <jhutz> rlbob, I think that exactly the point
[09:24:51] <marcos.sanz> Now about "attributes"
[09:24:59] <marcos.sanz> Features of me that the rest of the world might care about
[09:25:14] <ben> hmmm, what was the definition of credential?
[09:25:19] <marcos.sanz> About "assertion"
[09:25:20] <rlbob> the idworkshop list is currently debating "user-centric" and "federation", with people trying to claim "the true definition" of these words, with predictable results
[09:25:22] <cat> credential: thing I hand to somebody as a part of authentication that doesn't necessarily identify me
[09:25:22] <hartmans> ekr: agreed, your acronyms were useful. Although then we had to map them back to concepts.
[09:25:24] <cat> ... kinda
[09:25:56] <ekr> Sam: Totally.
[09:26:07] <jhutz> That was Leif Johansson
[09:26:09] <marcos.sanz> Problems we want to solve
[09:26:31] <marcos.sanz> •Capture-Resistant Credentials (CRC) •Hijack-Resistant Authentication (HRA) •Portable Credentials (PC) •Fill-in of Personal Information (FPI) •Common User Credentials (CUC) •Continuity of Identity (CI) •User-Friendly Names (UFN) •Assertion of External Claims (AEC) •Independent Assertion of Claims (IAC) •Private Authentication (PA)
[09:26:40] <jhutz> ekr, is this slide the ridiculous acronyms you were talking about?
[09:26:44] <marcos.sanz> Three newly just arrived:
[09:26:45] <marcos.sanz> •Single Site Unlinkability (SSU) •Multiple Site Unlinkability (MSU) •Attack Resistant Credentials (ARC)
[09:27:03] --- gregth has joined
[09:27:38] <marcos.sanz> Pete writes on the paper: Confidentiality
[09:27:41] <jhutz> I would argue that perhaps "CRC" was not a good choice of acronym :-)
[09:28:09] <tlyu> the other definition of "CRC" is less useful these days...
[09:28:24] <cat> Centre Radio-Canada ?
[09:28:26] <ben> he actually missed one of mine
[09:28:27] <rlbob> http://silmaril.ie/cgi-bin/uncgi/acronyms
[09:28:32] <ben> which was claim minimality
[09:28:34] <nico> heh
[09:28:59] <marcos.sanz> Pete writes on the paper: 2 kinds of credentials: a) usable by anyone b) tied to RP
[09:29:12] <Lisa> Ben, how is that different from Independent Assertion of Claims?
[09:29:21] --- fred.lefebvre has joined
[09:29:25] --- roland has joined
[09:29:31] <rlbob> ben: is minimality really different than independent-assertion?
[09:30:02] <tlr> Well, you get into the business of inferring assertions from the credential and then proving that inferred assertion without stating the original one.
[09:30:09] --- pigdog has left
[09:30:12] <gregth> if minimality means proving a property of an assertion (age > 21 when the assertion is age = 47), then it is different.
[09:30:42] <marcos.sanz> Pete crosses the word confidentiality and writes whitelisting (WL)
[09:31:01] <marcos.sanz> Ben states that there is one problem we want to solve missing: "Claim minimality"
[09:31:03] <ekr> I'm a bit skeptical of claim minimality as something we can actually do.
[09:31:04] <rlbob> yep, true
[09:31:17] <cat> ekr - I'm not all that skeptical about it myself.
[09:31:18] <ekr> No, wait, that's not true
[09:31:26] <ekr> It's easy to do with a proxy.
[09:31:26] * marcos.sanz thinks that claim minimality is IAC
[09:31:35] <gregth> the technology certainly exists.
[09:31:36] <Lisa> I think rather that claim minimality is dependent on the semantic of the claim genre and out of scope of what we'd likely do here.
[09:31:47] <ekr> There are two ways to do claim minimality:
[09:31:52] <rlbob> though IMHO that starts to edge way into application layer, eg similar to "support all image formats"
[09:31:58] --- pigdog has joined
[09:32:09] <marcos.sanz> PEte writes: Claim minimality (CM)
[09:32:14] <rlbob> lisa: yah, that's what I was trying to say
[09:32:25] <ekr> 1. have some server which knows the true claim and then generates customized derived claims. This has a privacy problem because the server then knows exactly what you're doing.
[09:32:55] <ekr> 2. Have some cryptographic mechanism that allows *you* to generate minimal claims. This is doable (sort of) but it's massive crypto rocket science.
[09:33:19] --- psangster has left
[09:33:56] <ekr> It's (2) I'm skeptical of.
[09:34:05] <Lisa> Your claim provider may or may not know your date of birth, and it may or may not know if you're over 21. These can be two separately requested/named attributes, one of which it may derive from the other dynamically, if the semantics of those attributes are defined somewhere.
[09:34:11] <Lisa> I agree skeptical of (2)
[09:34:12] --- gregth has left
[09:34:20] --- axelm has joined
[09:34:20] <rlbob> blakley makes a case for support of CM as a good bizniz model: http://inflectionpoint.burtongroup.com/ip/2006/06/identity_and_co.html
[09:34:20] <marcos.sanz> Sam describes at the mic one attack he0s trying to deffend against. This attack is 4.5 or 4.6 in his document. (which document?)
[09:34:27] <jhutz> ekr, without taking the time to explain how here, do you know how to do the crypto so someone can generate derived claims for the age example?
[09:34:35] <ben> claim minimality is not IAC - I mean you can prove a property of an assertion instead of showing the assertion
[09:34:49] <marcos.sanz> ben: understood
[09:35:11] --- JeffH has joined
[09:35:16] <ben> I agree with ekr's 2 methods, btw
[09:35:25] <pigdog> i detect a boiling of the ocean
[09:35:28] <ben> not so sure about the rocket science :-)
[09:35:34] <pigdog> (an attempt, that is)
[09:35:34] --- gregth has joined
[09:35:40] <ben> perhaps nuclear physics ;-)
[09:35:48] <JeffH> note that this is not only a list of "reqs" but also a list of "security properties"
[09:35:52] <rlbob> ben: are you unsure of it being heavily patented? :)
[09:36:05] <ben> most known methods are heavily patented
[09:36:14] <marcos.sanz> Pete tries to find a term to the problem that Sam and Ekr described
[09:36:23] <ekr> jhutz: I'm trying to remember, to tell you the truth. Obviously, there's a naive way where they give you bunch of attestations :)
[09:36:25] <ben> but: a) I believe Camenish-Lysyanskya's RSA-based stuff is not
[09:36:34] <marcos.sanz> Pete writes: Mutual proof partic. (MPP)
[09:36:35] <ben> and b) I've heard IBM are going to grant rights to their patents
[09:36:37] <Ted> phoffman suggests "pomp" proof of mutual participation
[09:36:39] <JeffH> ben: both flavors of it?
[09:36:46] --- mrex has joined
[09:36:47] <ben> so I've heard
[09:36:52] <JeffH> huh
[09:36:54] <ben> but don't quote me :-)
[09:36:58] <JeffH> ok
[09:37:00] <gregth> ekr: what makes you skeptical of (2)? the crypto is a) not rocket science, 2) provably secure, 3) practical on low-power client devices.
[09:37:11] <ben> that is: I am not authoritative on this claim
[09:37:19] <mnot> Is the title of this slide ("Problems we want to solve") accurate?
[09:37:21] <JeffH> heh
[09:37:26] <JeffH> no
[09:37:37] <JeffH> it's also "security properties"
[09:37:42] <mnot> that's much better
[09:37:47] <ekr> Given that the current state of the art in IETF crypto is HMAC, I think the crypto rates as rocket science by the current community standards.
[09:37:48] <mnot> otherwise, we might as well add "world hunger"
[09:38:03] <JeffH> mnot: sure, let's do that
[09:38:03] <jhutz> Yeah, I was thinking maybe you had something less naive in mind. If you do remember, let me know; that sounds interesting.
[09:38:06] <JeffH> ;-)
[09:38:25] <ekr> Re provably secure, I would refer you to http://eprint.iacr.org/2006/229
[09:38:27] <pigdog> PLEASE USE THE MIKE
[09:38:51] <JeffH> man, when u stand up in front of the crowd, yer flyin' blind, eh?
[09:38:55] <jhutz> No really. Adjust the mic. Don't just lean down for the first few moments.
[09:39:05] <cat> Take the mic out of the stand, hold on to it. Easy.
[09:39:21] <ekr> And anyway, some claims are easy to do with these techniques, some aren't. Each one needs to be custom-designed.
[09:39:31] <ekr> Which is what makes it problematic.
[09:39:47] <gregth> see: http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=3801
[09:39:49] <Jeffrey Altman> and once again he's not using the mic
[09:40:06] * marcos.sanz will remind people to use the mic
[09:40:09] <jhutz> Well, yeah; I wouldn't expect it to actually be generically useful. Just interesting from a theoretical standpoint.
[09:41:27] --- Peter Koch has joined
[09:41:36] <mnot> 99% of users won't have a clue about what mechanism to use, and 80% of them will use the "wrong" one if given the choice.
[09:41:55] <marcos.sanz> Lisa: would like to stop discussion on this particular topic
[09:42:08] <mnot> Besides which, the risk isn't entirely on the user side
[09:42:10] <jhutz> Thanks for the reference, ekr
[09:42:13] <nico> "trust anchor" is too PKI-specific
[09:42:25] <Jeffrey Altman> who was that?
[09:42:30] <jhutz> FIIN
[09:42:35] <marcos.sanz> That was Antti Mäkelä
[09:42:39] <Jeffrey Altman> thank you
[09:42:41] <ekr> BTW, the Koblitz-Menezes paper (The eprint URL I cited) is interesting.
[09:42:45] <jhutz> "trust anchor" is a concept, but not a problem
[09:42:50] <rlbob> but the interest of some entities in being trusted third parties is significant, I think
[09:43:05] <ben> trust anchors are only relevant to certain solutions
[09:43:12] <ekr> Ben: yep.
[09:43:12] <mrex> Sorry for coming late. I have some slight deja-vu (AAARG) a bells-and-whistles approach to security from the apps area because they don't like what is there (too complicated, to difficult)
[09:43:22] <nico> the title of the slide is wrong
[09:43:34] --- psangster has joined
[09:43:41] <marcos.sanz> (we are still in slide 5, btw)
[09:43:46] <ekr> "Problems or other acronyms we may or may not want to solve...."
[09:44:13] <pigdog> i don't know what that means
[09:44:42] <marcos.sanz> Pete thinks we have a good list so far
[09:44:42] <Ted> it means: "we don't have to invent the wheel"
[09:44:51] <rlbob> mrex: it's all security geeks here, no worries
[09:44:52] <pigdog> sure
[09:45:02] <JeffH> nico: us sec folk often hear "why is it so complicated?"
[09:45:06] <JeffH> as u know
[09:45:10] <JeffH> :)
[09:45:15] <marcos.sanz> Now Sam speaking
[09:45:21] <nico> yes
[09:45:25] <marcos.sanz> at the tribune
[09:45:33] <mrex> rlbob: Don't worry, I know many of the security geeks and am well aware of that
[09:45:35] <marcos.sanz> Title of his presentation "Web authentication and phishing"
[09:45:51] <kdz> http://www3.ietf.org/proceedings/06jul/slides/wae-1.pdf
[09:46:09] <cat> JeffH - sec folk have a bad habit of forgetting that we speak and understand a particularly obsure dialect, and have an inbuilt paranoia that many do not.
[09:46:16] <marcos.sanz> http://www.ietf.org/internet-drafts/draft-hartman-webauth-00.txt
[09:46:24] <marcos.sanz> (I think this is the draft)
[09:46:24] <JeffH> cat: of course, well put
[09:46:25] <Jeffrey Altman> http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-01.txt
[09:46:25] <Lisa> http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-01.txt
[09:46:27] <nico> dialect_s_
[09:46:33] <cat> *nods to nico*
[09:46:37] * marcos.sanz thanks Lisa
[09:46:48] <JeffH> cat: hence all my work on glossaries
[09:46:52] <marcos.sanz> and J.
[09:47:43] <marcos.sanz> http://www3.ietf.org/proceedings/06jul/slides/wae-1.pdf
[09:47:54] <nico> glossaries? dictionaries
[09:47:55] --- dumdidum has left
[09:48:01] <nico> like English-French
[09:48:02] <ekr> Actually, it's interesting to note that SRP-TLS meets all these requirements.
[09:48:06] <nico> French-English
[09:48:13] <nico> IPsec-Kerberos
[09:48:17] <ekr> To a first order TLS-PSK does.
[09:48:18] <JeffH> ekr: yes
[09:48:20] <nico> PKI-Kerberos
[09:48:22] <nico> ...
[09:48:26] <nico> :)
[09:48:27] <pigdog> mic: potential for other credentials is NOT a strong enough requirement for this group. MUST support stronger, MUST NOT require
[09:48:32] --- mnot has left
[09:48:34] <nico> SRP-TLS isn't enough
[09:48:40] <ekr> Nico: why?
[09:48:45] <nico> you have to turn off Basic and DIGETS
[09:48:47] <nico> :)
[09:48:49] <nico> :)
[09:49:07] <Lisa> I think we don't underrstand you Eliot
[09:49:14] <pigdog> must be able to support smartcards
[09:49:20] <mrex> even without active content, the many remotely exploitable bugs in feature-bloated browsers make almost any UI untrustworthy, except maybe something like S-A-k ( a UI revealed by a secure attention key) unless you're already running your browser with admin priviledges...
[09:49:21] <ekr> Oh, sure, but we're stipulating that somehow we need to turn off the dumb methods.
[09:49:34] <pigdog> we are absolutely going to have to support smartcards
[09:49:37] --- alexeymelnikov has joined
[09:49:39] <Lisa> oh you just want him to strike the word potential?
[09:49:43] <JeffH> phishing's first-order solutions are in the UI space, it seems
[09:49:44] <pigdog> right
[09:49:45] <jhutz> The problem with an SAK-based approach is that users will never "get it"
[09:50:09] <ben> what is a SAK?
[09:50:10] --- resnick has joined
[09:50:22] <nico> jeffh: they just have to be bound to what happens on the wire
[09:50:32] <nico> secure attention key
[09:50:38] <nico> sak
[09:50:48] <nico> ctrl-alt-delete
[09:50:54] <nico> that sort of thing
[09:51:14] --- ldondeti has joined
[09:51:44] --- dumdidum has joined
[09:51:45] <ben> yeah, I read the words, I still want to know what a SAK _is_
[09:51:47] <jhutz> "secure attention key" Essentially, a keystroke or other input event which gets you to a known, system-defined interface.
[09:51:52] <mrex> on windows ctrl-alt-delete gets you to a "windows station" where regular apps have no access an can not display/intercept, Something similar is available for Unix X-Servers (there was some provider for a secure Solaris)
[09:51:53] <ben> ah
[09:51:58] <ben> trusted path, effectively
[09:52:20] <Lisa> Making pete exercise? :)
[09:52:30] <ben> I've heard this claimed, but I've seen ctl-alt-del intercepted
[09:52:32] <jhutz> The SAK cannot be captured, so malicious software cannot trick you into thinking you're talking to the OS when you're really not.
[09:53:07] <jhutz> On windows, ctrl-alt-delete cannot be intercepted; it belongs to the OS, always.
[09:53:20] <jhutz> It is a real secure attention key.
[09:53:29] <cat> jhutz - do you have a link for that?
[09:53:36] <ben> possibly true from NT onwards
[09:53:36] <jhutz> Not offhand.
[09:53:42] <jhutz> Yes, only in NT-series
[09:54:24] <jhutz> Don't be confused by the use in DOS of ctrl-alt-delete to reboot the system, which is not the same as a reset button.
[09:54:29] <marcos.sanz> Presentaiton over
[09:54:35] <pigdog> thank you sam
[09:55:05] <marcos.sanz> Pete back to the main presentation
[09:55:14] <marcos.sanz> Last slide
[09:55:18] <ekr> S-A-K assumes that the attacker hasn't compromised the OS, which seems like a weak assumption.
[09:55:21] <nico> mrex: the X server can have sak's, I'm sure
[09:55:34] <nico> ekr: no, that's a required assumption, even if weak
[09:56:00] <nico> sure, sure, smartcards, yaddy, yaddy, yadda
[09:56:01] <jhutz> If the attacker has compromised the OS, you lose.
[09:56:06] <ben> nico: agreed, securing the OS is orthogonal, but a prerequisite :-)
[09:56:22] <nico> even with smartcards, os compromise == you lose
[09:56:22] <mrex> if we can not rely on the integrity of the underlying OS, then there is no way for us to solve the problem in Software
[09:56:42] <marcos.sanz> Pete writes: Attribute (FPI)
[09:56:44] <nico> we can solve all the world's problems
[09:56:47] --- pigdog has left
[09:56:48] <ekr> Well, I agree that some level of assumptions about the security of the end-user's system is critical. But since privilege escalation is so easy, assuming OS integrity may just reduce to assuming security of the user's computer.
[09:57:08] <nico> local security is a pre-req, but not a problem space where the IETF has any role
[09:57:23] <hartmans> BTW, my draft does discuss trusted UIs which gets you to SAK etc
[09:57:23] <nico> local security is the OS (and application) vendors
[09:57:24] --- pigdog has joined
[09:57:24] <ben> capability OS, its the only way to be sure
[09:57:31] <nico> / implementors
[09:57:43] <ekr> IBM 4758, it's the only way to be sure.
[09:57:48] * marcos.sanz is pressuming that everybody has the audio feed. If this is a problem, please let me know.
[09:57:58] <nico> to be sure of what?
[09:58:01] <jhutz> Even a true capability-based system can have bugs
[09:58:06] <nico> so you don't lose your private keys
[09:58:08] <pigdog> looks to me like a pre-charter discussion
[09:58:14] <nico> but you still lose your money
[09:58:30] <mrex> nico: (a) if the smart-card isn't broken, even a compromised OS cannot steal the credential. (b) if the smart card reader requires a PIN for each signature (and the PIN prompting and passing-to-smartcard is local to the smartcard reader, then there is a limit on the number of signatures that a compromised OS can get from the credential
[09:58:36] <ekr> Actually, I've found Multics to be very secure.
[09:58:39] <nico> I don't think not losing their keys will make the users feel any better about their money being stolen
[09:58:40] <Lisa> Marcos, we still need to derive notes that include what was said.
[09:58:43] <marcos.sanz> Pete switches to a new slide:
[09:58:52] <Lisa> Unless somebody is willing to review the audio feed later to derive the notes.
[09:59:01] <marcos.sanz> Problem breakdown & Desirable functionality
[09:59:02] <ben> you are just moving the problem elsewhere - smartcards have OSes, too
[09:59:06] <nico> mrex: if the OS is compromised you may not know it
[09:59:09] --- woj has joined
[09:59:11] <ben> and they have no UI
[09:59:12] * marcos.sanz thought there was a minute taker in the room
[09:59:16] <ekr> Computing RSA on an abacus is the endgame here.
[09:59:28] <ben> so you say "sign your mail" and get the smartcard to write a cheque instead
[09:59:32] <nico> the attacker may wait and wait for the right opportunity to steal your money
[09:59:52] <jhutz> Martin: most smartcard deployments do not use mechanisms where the pin-entry-to-smartcard path is secure. Readers with direct PIN entry are more expensive, and may still be untrusted.
[09:59:53] <marcos.sanz> a) Phishing. Account credentials (CRC, HRA, PC?, CUC, CI?), IDentity attributes (Certainty of website identity, secure channel to prevent eavesdropping)
[09:59:56] <nico> smartcards could be made to have UIs
[10:00:08] <pigdog> nico: some do
[10:00:10] <gregth> and, in fact, have, back in the 90s
[10:00:11] <nico> that still wouldn't make the local security problem go away
[10:00:21] <jhutz> Some do, and those are expensive, too.
[10:00:21] <ekr> Nico: http://www.usenix.org/publications/library/proceedings/sec99/balfanz.html
[10:00:22] <marcos.sanz> b) Software Assisted Attribute Exchange. Actions: request, response store (FPI, CI?,UFN?,AEC,IAC,PA)
[10:00:44] <mrex> this is why I have been asking for a security evalutated (EAL4 or higher) smart card reader with PINpad and visualization component for decades
[10:00:58] --- dumdidum has left
[10:01:00] <tlr> lisa, that would strike me as another layer of the discussion
[10:01:02] <mrex> :-)
[10:01:04] <marcos.sanz> Pete writes: Anti-Phishing
[10:01:08] --- woj has left
[10:01:12] <Lisa> Hmm, then there may be another problem or two we're missing...
[10:01:44] <jhutz> Gee, I can't imagine why Lisa would care about those. :-)
[10:01:47] <Lisa> Yeah, it's all in the blah blah blah :)
[10:02:01] <pigdog> mic: POP/IMAP/SMTP/etc as well,please
[10:02:07] <marcos.sanz> Pete writes: Non-browsing support
[10:02:19] <pigdog> eg, non-http
[10:02:36] <ekr> Well, so POP/IMAP/SMTP already has SASL... It would clearly be an improvement to add the mechanisms SASL already has to HTTP.
[10:02:55] <pigdog> or to add SASL to HTTP?
[10:03:01] <pigdog> but now we're into solutions
[10:03:03] <nico> ekr: like GSS mechanisms
[10:03:11] <pigdog> i think we're talking about a couple of new SASL methods, myself
[10:03:13] <ekr> pigdog, nico, right.
[10:03:13] <Ted> Problem sam wants to solve "I have this infrastructure, and I want to apply it to the web"
[10:03:17] <JeffH> pigdog: yes, and what ekr just said about gss
[10:03:19] <cat> pigdog - I hope we aren't. SASL's a pain.
[10:03:25] <nico> pigdog: maybe, but think of it as "we want the credentials types that work there to work here"
[10:03:32] <marcos.sanz> Pete writes: support for existing infrastr.
[10:03:43] <nico> and "we want to re-use off-the-shelf components as much as possible"
[10:03:44] --- mnot has joined
[10:03:45] <JeffH> SASL's useful when designing protocols
[10:04:00] <JeffH> given its largely a protocol design pattern
[10:04:03] --- dumdidum has joined
[10:04:26] <nico> jeffh: the same is true of the GSS-API
[10:04:35] <pigdog> this "supporting existing infrastucture" concerns me just a bit. it has to be able to do the job to deal with phishing, eliot's dad's problem, etc. if it can do all that with existing infrastructure, fine, but one would have to ask why it hasn't been done
[10:04:45] <JeffH> nico: yes, tho a deep conversation we've had some of this week
[10:04:49] <cat> pigdog
[10:04:56] <pigdog> ?
[10:04:57] <Ted> you can also re-use the infrastructure, without sharing the credentials
[10:05:05] <hartmans> I think it is more than credentials.
[10:05:07] <cat> Sorry - I hit enter before finishing my sentence.
[10:05:17] <jhutz> The infrastructure Sam's talking about is authentication infrastructure.
[10:05:31] <nico> hartmans: yes, and the identities/attributes that those credentials are used to convey
[10:05:32] <jhutz> e.g. I want to use my existing Kerberos infrastructure to authenticate web apps
[10:05:34] <pigdog> in other words, let's be as backward compatible as possible, while still solving the problem ;-)
[10:05:37] <jhutz> ... within my enterprise
[10:05:41] <mrex> for many customers, the "existing infrastructure" is equal to passwords
[10:05:42] <ben> support for existing infrastructure should not imply that you have to use existing infrastructure
[10:06:09] --- tonyhansen has joined
[10:06:17] <marcos.sanz> P rewrites to Non-browsing HTTP-support
[10:06:20] <ekr> So, this SASL-HTTP thing is a bitch, for a bunch of technical reasons.
[10:06:23] <cat> ben - no, but it's easier to get adoption if you don't start with "throw everything you've got out"
[10:06:24] <pigdog> ben, i just don't know what that means
[10:06:26] <jhutz> Part of what we're getting at is that a solution should not mandate a particular authentication technology.
[10:06:27] <nico> mrex: so that brings us to: upgrade
[10:06:29] <marcos.sanz> Pete writes X-app credentials (XAC)
[10:06:35] <jhutz> ekr, yes, it is
[10:06:44] <ekr> You sort of end-up with SASL + TLS + Channel Bindings.
[10:06:51] <nico> ekr: yes, we want GSS-HTTP
[10:06:53] <cat> pigdog - Just because you can use existing infrastructure doesn't mean that you should or have to...
[10:06:58] <nico> ekr: yes!
[10:07:00] <nico> channel bindings
[10:07:02] <nico> you do TLS
[10:07:03] <tlyu> introducing a new technology with no credible migration path is a fairly good way to prevent the new technology from getting adopted
[10:07:07] <Lisa> pigdog, adding SASL to HTTP is *really* problematic. If somebody explains to me how it can actually work with proxies and statelessness" and everything, I will publicly call them a genius.
[10:07:14] <ekr> nico: maybe I'm out of the loop, but I thought that SASL was considered to be the cool way to do GSS now.
[10:07:15] <nico> you authenticate using a framework protected by TLS
[10:07:21] <nico> and channel bind
[10:07:25] <nico> ekr: no
[10:07:33] <ekr> Oh, OK. Guess I misunderstood Sam.
[10:07:35] <rlbob> lisa: a gang of geniuses are working on a draft on this right now
[10:07:42] <nico> ekr: we want mechanism portability across frameworks
[10:07:47] <Lisa> That's good to know
[10:07:48] <nico> GSS is more general
[10:07:58] <nico> it's message-oriented
[10:07:59] <hartmans> Lisa, we believe we have gss http auth very close; sasl proved too difficult.
[10:08:09] <Lisa> It would be easy to graft SASL *under* HTTP but *into* is hard.
[10:08:12] <nico> think SASL is to GSS as TLS is to DTLS
[10:08:13] <jhutz> Yes, we think apps should use sasl, when they can. Much of that is because it's easier to use and gives you a wider choice of mechanisms (since at least in theory, any GSS mech can be made into a SASL mech). But sometimes it's appropriate to use gss directly.
[10:08:20] <hartmans> SASL is the new way to do gss if you live within sasl constraints.
[10:08:22] <mrex> authentication and statelessness is close to impossible
[10:09:08] <mrex> SSL/TLS is certainly not stateless (usually the middleware keeps state, though)
[10:09:27] <nico> mrex: if exported partially established security contexts are supported then one can send encrypted exported partially established security contexts as a way of avoiding statefulness
[10:09:42] <nico> mrex: I expect only GSS weenies like us will get that
[10:09:50] <nico> I'll be glad to explain that to others later
[10:10:31] <nico> mrex: we only need to worry about the TLS between the client's last proxy and the server's first; middleware is not that much of an issue
[10:10:33] <jhutz> True, but what mechs support that today?
[10:10:50] <pigdog> mic/Ted/Sam: to me it's a MUST. Otherwise you will have extremely perverse effects of people even MORE inclined to use HTTP as a transport/IP than before. it's the end of IMAP and perhaps email transmission
[10:11:14] <pigdog> and this should be an attainable requirement.
[10:11:14] <nico> juhutz: you talking to me?
[10:11:19] <jhutz> yes
[10:11:23] <pigdog> i'm not looking for the same verbs in every protocol
[10:11:27] <nico> it's an implementation matter
[10:11:31] <Ted> pigdog: I think you are mis-MUSTing.
[10:11:35] <nico> we can make that work w/o protocol work
[10:12:04] <nico> (we may need to clarify that GSS_Export_sec_context() MAY support exporting partially established sec contexts)
[10:12:05] <Ted> The ability to work across protocols and keep the same infrastructure and hit all of the use cases here is an ocean
[10:12:05] <pigdog> ted: let's take it to email.
[10:12:25] <Ted> pigdog: okay-fine
[10:12:55] --- Jerry Shih has left
[10:13:14] <rlbob> eliot: the web has usage characteristics very different from email. I don't want to read my email from potentially hundreds of sites, just one or two.
[10:13:23] <jhutz> Actually, the real issue is you need to design the app protocols to make it work. And then you have an app protocol (or implementation of such) which is responsible for wrapping up an exported context (partially-established or not) in a secure fashion for the client to transport.
[10:13:35] <JeffH> <catching up here, standing at mic is really flying blind>
[10:13:50] <pigdog> rlbob: but i want to have one password for my email application and my other applications
[10:13:50] <nico> heh
[10:14:01] <marcos.sanz> pigdog: Ok, then it will not go to the mic
[10:14:02] <hartmans> Can we not have an in-depth GSS design discussion it the middle of the BOF?
[10:14:07] <JeffH> so I never meant to imply re-specifying http with sasl support was workable or desirable
[10:14:13] <cat> jeffh - ah.
[10:14:23] --- agallant has left
[10:14:27] <JeffH> I was speaking in abstract as a protocol designer overall
[10:14:27] <jhutz> fortunately, I don't think we need to work across protocols here. I think it's fine here for things that work at the http layer to be specific to that layer. We already _have_ auth mechanisms and frameworks that work with multiple protocols
[10:14:31] <jhutz> you're no fun :-)
[10:14:34] <nico> think keep alive is optional
[10:14:42] --- dumdidum has left
[10:14:43] <nico> thu gss is a much better fit
[10:14:50] <mrex> jhutz: this doesn't change the fact that things are stateful -- it just puts most of the burden of keeping the state on the client
[10:14:57] <JeffH> nico characterized it to me pretty well earlier this week wrt salient diffs btwn sasl & gss
[10:14:58] <jhutz> true
[10:15:01] --- robyates has joined
[10:15:07] <JeffH> sasl is stream-oriented, gss is msg-oriented
[10:15:10] <pigdog> ekr, that's what i hope, as long as we don't go off and use some whacky http approach that binds to tightly to the protocol
[10:15:30] <jhutz> jeffh, that's a bit of an oversimplification, but yes
[10:15:31] <pigdog> e.g., perverse use of cookies or something like that
[10:15:34] <marcos.sanz> Lise goes to the paper and writes a new slide
[10:16:04] <JeffH> jhutz: agreed
[10:16:34] <jhutz> mrex, yes, but when we talk about statelessness, we mostly care about the server rather than the client
[10:16:47] <marcos.sanz> Lisa writes: EKR1, fix Web Auth (non-insane digest repl, anti-phishing). EKR2, cross-site identity, eliot's dad's Proto. EKR3, claim & Attribute, Transferral.
[10:16:53] <JeffH> hm,if we had everyone hold their systems in the mic line, mebbe it's self-drain
[10:17:01] <Jeffrey Altman> I cannot agree that phishing is limited to the financial sector
[10:17:15] <jhutz> me either. but well, phb
[10:17:23] <ekr> Lisa's rational reconstruction of my categories is about right.
[10:17:26] <mrex> jhutz: if it was really stateless, then it wouldn't matter if there was a load-balancer in between that made followup requests end on different machines
[10:17:37] <pigdog> ekr: sounds good
[10:17:41] <rlbob> jhutz: are you aware of phishing attacks targeting any university-hosted apps?
[10:17:50] <marcos.sanz> Eliot's Dad problem, that's it.
[10:17:59] <hartmans> mrex: I believe we can achieve that level of stateless.
[10:18:08] <Lisa> Ekr, it's good to know I understand you now and then.
[10:18:18] <jhutz> what nico describes can be made to have that level of statelessness, if you do it carefully.
[10:18:26] <pigdog> you'd think the two of you were related or something ;-)
[10:18:32] <rlbob> you have to marry him to understand him? :)
[10:18:40] <Lisa> I plan to try to ask for some consensus around that breakdown.
[10:18:43] <mrex> but it would require at least synchronization of the acceptor side credentials
[10:18:47] <cat> *nods to Lisa.*
[10:18:50] <ekr> Part of what's confusing here is that there's a lot of commonality in the technical mechanisms people often implement to do EKR1 and EKR2.
[10:18:52] <jhutz> I like that breakdown
[10:18:56] <mrex> (for a server farm involving load balancing)
[10:19:09] <ekr> Though not always, though people often want to use passport-style things for EKR2.
[10:19:10] <pigdog> ekr: to me that just means less code
[10:19:11] <Lisa> And there's a lot of overlap between 2 and 3.
[10:19:15] <nico> oh man
[10:19:17] <nico> catch up time
[10:19:23] <pigdog> Is this URI?
[10:19:26] <nico> catch up or pay attention to the mic discussion
[10:19:29] <marcos.sanz> Uril Blumenthal speaking
[10:19:29] <Lisa> And the two parts of #2 could be completely separated!
[10:19:29] <nico> can we slow down?
[10:19:34] <nico> yes, it's Uri
[10:19:36] <nico> :)
[10:19:40] <jhutz> the underlying auth protocols for EKR1 and EKR2 may often be similar, but the ways in which they are deployed and used will be different.
[10:19:51] <nico> so, mrex, jhutz, others
[10:19:55] <jhutz> Particularly with regard to how you get acceptor credentials.
[10:19:58] <nico> you're missing a few things
[10:20:11] <jhutz> can we defer the gssapi design discussion for later?
[10:20:16] <nico> first, as ekr mentioned, we want channel binding
[10:20:35] <ekr> jhutz: yeah, though it's worth noting that SRP-style mechanisms serves much the same purpose in both.
[10:20:41] <nico> second, we want to do that over HTTP with multi-round-trips if need be, and we don't want to require HTTP 1.1 and keep alive
[10:20:43] <nico> oops
[10:20:50] <nico> thus GSS is a better fit than SASL
[10:21:04] <nico> Internet-Drafts will be forthcoming :)
[10:21:14] <mrex> nico: I don't like channel binding in anyway, because they create a lot of problems
[10:21:22] --- washad has left: Computer went to sleep
[10:21:27] <jhutz> well, but srp-style mechanisms don't really solve EKR2, IMHO. They tend to involve pairwise credentials, so you effectively have a distinct identity per service
[10:21:34] <nico> GSS is a better fit because, though TLS is a stream oriented protocol, and SASL is too, HTTP is message oriented
[10:21:36] <cat> Hm. Who's at the mic?
[10:21:40] <Lisa> Mark Nottingham
[10:21:41] <nico> and we're talking about HTTP, not TLS
[10:21:41] <marcos.sanz> Mark Nottingham
[10:21:52] <jhutz> Nico, I'm not arguing that GSS is not a better fit than SASL. I don't think mrex is, either.
[10:21:54] <Lisa> He's now the IETF's liaison to the W3C, BTW
[10:21:55] <nico> mrex: we need to talk
[10:22:07] <ekr> jhutz: trying to remember whether you can provide the verifier to the server or whether it computes it.
[10:22:18] <mrex> the only reason to use channel bindings would be to tie a disclosing authentication to a particular unique cryptographically secure session at a lower layer
[10:22:20] --- dumdidum has joined
[10:22:23] --- pigdog has left
[10:22:30] <jhutz> mrex, GSSAPI's approach to channel binding has problems, but the concept is both sound and important. more offline
[10:22:30] <nico> ekr: depends on the channel binding app
[10:22:34] <nico> in this case...
[10:22:38] <nico> can we save this for later?
[10:22:46] <ekr> Looks like you can.
[10:22:49] <marcos.sanz> Lisa describes now her taxonomy on the board
[10:22:49] <nico> jhutz: excellent
[10:23:10] --- pigdog has joined
[10:23:32] <marcos.sanz> She rewrites "Fix WebAuth" to "Fix HTTP-Auth"
[10:24:01] <mrex> jhutz: channel binding ties protocol layers together that ought to be independent
[10:24:03] <ekr> I'm trying to remember what I meant by EKR1, since I've been claiming that Digest is just A-OK :)
[10:24:11] <mnot> heh
[10:24:20] <jhutz> Does EKR1 include making web auth secure with other mechanisms. Like, is GSS+TLS+channel bindings (or what that solves) in scope for that?
[10:24:23] <ekr> Actually, it's not, since it doesn't have mutual auth (per Sam) or binding to TLS.
[10:24:41] <jhutz> maybe you meant channel bindings?
[10:25:01] <mrex> a single universal transport with direct connectivity to every end system doesn't exist, so channel bindings create lots of architectural problems
[10:25:17] <jhutz> martin, please, let's take that issue offline.
[10:25:37] <jhutz> I think you're somehow behind on what we're really talking about wrt channel bindings
[10:25:56] <jhutz> hint: we don't mean binding to the transport layer
[10:26:08] --- pigdog has left: Replaced by new connection
[10:26:13] <nico> we mean binding to secure channels
[10:26:22] <JeffH> i wonder how fast ekr can speak if he really wants to
[10:26:23] <marcos.sanz> Lise completes her board text: s/Anti-phishing/Anti-phishing: GUI, Mut. Auth./
[10:26:31] --- alexeymelnikov has left
[10:26:40] <marcos.sanz> Lisa strikes "non-insane digest repl"
[10:26:45] <jhutz> jeffh, let's try not to think about that
[10:26:49] <cat> JeffH - I'd like to hear him sing the major generals song
[10:26:56] <mrex> nico: I mentioned it before "SSL Accellerators" are becoming more and more popular
[10:27:02] <JeffH> cat: ;-)
[10:27:03] <nico> that's OK
[10:27:05] --- alexeymelnikov has joined
[10:27:12] <marcos.sanz> Thus EKR1 looks like: Fix HTTP-Auth, Anti-phishing: GUI, Mut. Auth
[10:27:19] <nico> mrex: we can make it work even with those
[10:27:20] <tlyu> "i am the very model of a modern network architect"...
[10:27:27] <JeffH> I wish I could dump buffers as fast as ekr
[10:27:27] <nico> in fact, we're trying hard
[10:27:36] <nico> more on that later
[10:28:09] --- pigdog has joined
[10:28:15] <mrex> on todays Web, end-to-end TLS is often not available
[10:28:25] <nico> we don't need it
[10:28:27] <jhutz> martin, later, really
[10:28:36] <rlbob> merrells wrote a large set of specific scenarios for dix ...
[10:28:37] <JeffH> nico: cuz of channel bindings?
[10:29:07] <nico> jeffh: no, well, yes, but because we only care about the portion of the client/server comms going over the big bad 'Net
[10:29:18] <jhutz> I think nico and/or I can bring you around to our current thinking, but it will take cycles we can't spend while still paying attention to the bof
[10:29:20] <nico> that'd be between the client's last proxy and the server's first (concentrator)
[10:29:30] <nico> jhutz: exactly
[10:29:50] <nico> end2end TLS isn't necessary, let's just say
[10:30:02] <nico> in fact, requiring it would be a non-starter
[10:30:11] <nico> now I'm going to listen to Uri
[10:30:13] <ekr> So the number of independent symbols in a crypto protocol is a metric of its complexity:
[10:30:16] <ekr> Here's SRP
[10:30:27] <ekr> N A large safe prime (N = 2q+1, where q is prime) All arithmetic is done modulo N. g A generator modulo N k Multiplier parameter (k = H(N, g) in SRP-6a, k = 3 for legacy SRP-6) s User's salt I Username p Cleartext Password H() One-way hash function ^ (Modular) Exponentiation u Random scrambling parameter a,b Secret ephemeral values A,B Public ephemeral values x Private key (derived from p and s) v Password verifier
[10:30:30] <ekr> Gah!!!
[10:30:42] <nico> ekr: that's why we make a mechanism out of it and analyze it
[10:30:54] --- bhoeneis has left: Replaced by new connection
[10:31:00] <nico> then we fit that elsewhere and analyze the result, etc...
[10:31:12] <marcos.sanz> Lise adds to EKR1: "Passwords AND other"
[10:31:44] <pigdog> +1
[10:31:55] <marcos.sanz> A fair amount of people for working on fixing EKR1
[10:32:12] <ekr> nico: the problem is that the analysis of SRP-6 isn't really that extensive.
[10:32:18] <rlbob> i'd say 20 people or so
[10:32:20] <nico> sure
[10:32:22] <ekr> And AFAIK there's no security proof (assuming, of course, you value those things)
[10:32:24] <nico> ekr: that's a problem
[10:32:34] <nico> but we need to abstract analysis
[10:32:38] <ekr> Oh, I agree.
[10:32:40] <nico> boxes
[10:32:44] <nico> y'know
[10:32:44] <jhutz> Hm. Isn't it amusing that "Big Bad Net" has the same initials as "Bolt, Beranek, and Newman"
[10:32:48] <nico> else we give up now
[10:32:52] <nico> :)
[10:32:58] <ekr> jhutz: you think that's a coincidence?
[10:33:49] <marcos.sanz> Lisa ellaborates on the board about EKR1
[10:34:21] <marcos.sanz> Antiphishing: GUI, Mutual Auth -> Liaise with W3C
[10:34:33] <marcos.sanz> Passowrds AND other
[10:35:18] <JeffH> http://www.antiphishing.org/
[10:35:26] <JeffH> google: APWG
[10:35:56] <pigdog> AGREE
[10:36:11] <pigdog> (no GUI requirements)
[10:36:39] <Ted> suddenly, the line at the mic gets long
[10:37:03] <Ted> tlr is now talking about w3c context work
[10:37:11] <ekr> ISTM that there are three categories of things we could say about GUI:
[10:37:12] <ekr> 1. Nothing.
[10:37:14] <Ted> gui requirements, best practices, and so on
[10:37:24] <jhutz> I think the answer to Lisa's question is "no, we do not have a consensus"
[10:37:33] <marcos.sanz> tlr is Thomas Roessler
[10:37:48] <ekr> 2. "Implementations must clearly indicate to users when a password is being typed into a trusted interface"
[10:37:50] <ben> I love it
[10:37:55] <Ted> I think being clear in IETF documents about what the http layer is good, but flash and other interfaces would have to pay attention
[10:38:00] <ben> the antiphishing website has an expired cert
[10:38:08] <cat> *ROTFL* How apropos.
[10:38:13] <ekr> 3. "This is how the dialogs must look..."
[10:38:18] <marcos.sanz> Lisa clarifies on the board: "Liaise to w3c on GUI, HTML & links to HTTP"
[10:38:20] <jhutz> I think (2) and similar statements are UI requirements but not GUI requirements.
[10:38:34] <jhutz> We clearly should not do (3)
[10:38:36] <ekr> Right. I think (2) is what's appropriate.
[10:38:40] <mrex> As long as HTML/HTTP-based apps (i.e. through active content or applets) are able to create password prompts indistinguishable from the real ones, the problem of phishing can not be solved for the majority of (web) service providers.
[10:38:43] <ekr> And we certainly have done so before.
[10:38:45] <jhutz> So do I
[10:38:54] <ben> Someone should do 3, however
[10:39:18] <ekr> Yes.
[10:39:25] <ekr> Gooooooggggglllleeeee.......
[10:39:35] <mrex> and no matter what we think and how convincingly we can explain it, passwords are going to be with us for long time
[10:39:42] <ekr> Passwords rock, dude.
[10:39:48] --- xmlscott has joined
[10:39:57] <jhutz> Ugh; the mic discussion would benefit from the distinction we just made. Now we are having disjoint discussion.
[10:40:10] <nico> mrex: thus my comment about UIs
[10:40:23] <marcos.sanz> Please, comments to the mic to be prefixed with "mic"
[10:40:58] <xmlscott> http://www.w3.org/TR/NOTE-authentform
[10:41:10] <marcos.sanz> The queue length at the mic remains constant
[10:41:11] <pigdog> we must be very careful on UI reqts because we as an IETF community have very little competence on UIs
[10:41:18] <nico> ekr: I don't agree with that distinction
[10:41:34] <Ted> But clearly the ability of a browser to invoke flash/java/javascript etc. means that preventing the author labeling a field as "password" is a darn big problem
[10:41:35] <xmlscott> User Agent Authentication Forms http://www.w3.org/TR/NOTE-authentform
[10:41:36] <nico> there's other things to say that you didn't mention
[10:41:45] <jhutz> sure, but the point of (2) is that we don't design the UI, which we don't have competence in, but we do indicate things that need to be user-visible
[10:41:47] <nico> we don't have to do that here and now
[10:41:54] <pigdog> mic: we must be very careful on UI reqts because we as an IETF community have very little competence on UIs
[10:42:06] <nico> the point is: we'll work with the W3C to obtain requirements
[10:42:29] <nico> shit, I missed everything Uri said
[10:42:33] <pigdog> i think there is confusion about which direction the requirements flow
[10:42:41] <tlyu> i think more than "UI" we want to deal with "human factors" which historically we've neglected somewhat at least in the security area
[10:43:30] --- bhoeneis has joined
[10:43:40] --- Ted has left
[10:44:35] <pigdog> EKR: +1. it's the equivalent of the old "print/log a diagnostic". we don't tell people how to do that
[10:44:50] <ekr> I think Empirical Science is probably a bit of a stretch based on the human factors research I've read.
[10:44:52] <rlbob> where [user makes security decision] and [info available to user at that time] are things that can be written into protocol flows
[10:45:05] <nico> +1 to tlyu, ekr
[10:45:16] <jhutz> UI's are hard, and yes, UI's are an empriical science. In fact, CMU has a whole department that does that. And yes, neither IETF nor W3C is going to do that science, or should.
[10:45:27] <jhutz> Of course, it's not clear the browser vendors will, either. :-(
[10:45:57] <pigdog> jhutz: some of them want to fix this stuff, I'm sure
[10:46:03] <marcos.sanz> Lisa adds to EKR1: "Layer/Arch. TBD"
[10:46:31] <tlyu> security protocols do not exist in a vacuum. without considering the human factors, you might design something which is secure under assumptions which are invalidated by the human factors in reality
[10:47:10] <pigdog> tlyu: it's fair to take human factors into account, but let's not think we're good at it
[10:47:25] <nico> better try than ignore them
[10:47:43] <marcos.sanz> Lisa adds to EKR1: Can stand alone, would need to coordinate
[10:47:45] <JeffH> so one shows up in mult venues and ropes-in subject-matter experts as appropriate ;-)
[10:47:46] <pigdog> this is a good one to ask for help
[10:48:05] <marcos.sanz> Lise has a new paper at the board, about EKR2:
[10:48:21] <marcos.sanz> Cross-site Identity
[10:48:31] <tlyu> it's a very short leap from "we're not competent to analyze human factors" to "we're going to ignore human factors". i would like us to stop making that leap.
[10:48:35] <marcos.sanz> a) Eliot's Dad's Problem (too many passwords -> use the same)
[10:48:42] <pigdog> {here's the dirty little secret: eliot has "Eliot's Dad's Problem"
[10:48:56] <cat> tlyu - or "human factors can be left to the implementors"
[10:49:20] <rlbob> we are all our parents ...
[10:49:23] <jhutz> Yes, for someone in his age group, Eliot's dad is pretty cool.
[10:49:24] <pigdog> EKR: CLOSER TO THE MIKE
[10:49:55] <nico> rlbob: no, we become them
[10:50:08] <nico> ;)
[10:52:01] <pigdog> It's not clear that my dad needs to worry about security of storing USER NAMES. passwords, on the other hand, are another matter. the USERNAME problem is solved by browsers today.
[10:52:36] <rlbob> eliot: my browser stores my passwords too ... ?
[10:52:53] <pigdog> can do. but you should be a little nervous about that.
[10:53:07] <jhutz> the user name problem is solved today, for eliot's dad.
[10:53:13] <mrex> today browsers solve the password issue, too -- and it will be quite difficult to take it away from them once they've got used to it
[10:53:16] <cat> pigdog - sounds like the convenience/security tradeoff again.
[10:53:27] <nico> mrex: not with mobility
[10:53:28] <JeffH> yup
[10:53:35] <pigdog> mrex: it's a matter of how much we want to trust the browsers.
[10:53:39] <gregth> use a usb keyfob
[10:53:50] <cat> gregth - so I lose my keyfob...
[10:53:52] <nico> which you plug into...?
[10:53:53] <pigdog> gregth: such a fob could also start my car
[10:53:59] <nico> kiosks?
[10:54:10] <pigdog> the fob needs a ui, tho
[10:54:10] <nico> pigdog: and give your money away
[10:54:13] <jhutz> But the cross-site identity issue is harder, because it's about doing what ekr just said at the mic - using an existing relationship with some site to establish a relationship with another, rather than doing pairwise user registration
[10:54:23] <nico> the fob needs to be a fullblown computer
[10:54:24] <mrex> we don't want to trust the browsers. browsers remembering the passwords in the way they do today is a security problem
[10:54:26] <nico> just very small
[10:54:35] <nico> of course, that describes my cell phone
[10:54:48] <pigdog> nico: your cell phone isn't modular enough for my tastes.
[10:54:58] <pigdog> but sure, Nokia would love to own this one
[10:55:02] <nico> pigdog: that's a matter of time
[10:55:12] <jhutz> if you make it too modular, there will be viruses
[10:55:27] <nico> and anyways, it doesn't have to be modular
[10:55:38] <nico> it needs a sufficiently full featured browser
[10:55:43] <pigdog> nico: i think things are going the other way. cell phones are getting more complex not less. virii are starting to appear on java os
[10:55:45] <rlbob> mrex: could you describe the threat represented by my browser storing my passwords, and suggest how I solve it in an approximately equally convenient way?
[10:55:47] <pigdog> on phones
[10:55:56] <nico> and monitor out port
[10:55:56] --- axelm has left: Replaced by new connection
[10:56:10] <marcos.sanz> Lisa deletes Eliot's Dad's Problem from EKR2 description
[10:56:18] <nico> and keyboard in (USB, perhaps, but well protected)
[10:56:23] <jhutz> (EDP is now EKR4)
[10:56:30] <marcos.sanz> So EKR2 now is: Cross-site IdentitIES
[10:56:47] <pigdog> i think the separation makes sense
[10:56:57] <nico> which separation?
[10:57:00] <ekr> So, I think of these as having a sort of loose hierarchy. Starting at the botto and working up.
[10:57:22] <pigdog> ekr2 splitting of edp
[10:57:24] <nico> but anyways, we don't all have such full-featured cell phones... yet
[10:57:24] <jhutz> rlbob: there are all sorts of issues with browser bugs, poor security of the file storage used, etc. But for some people, the mobility issue at least as important as the security issues
[10:57:26] <ekr> EKR1, EKR4(EDP), EKR2, EKR3.
[10:57:49] <nico> and when we do we can make digital cash tokens out of them too (don't lose your cell phone!)
[10:58:01] <jhutz> It took us long enough to agree to call it EKR4; renumbering would have been painful
[10:58:10] <ekr> Heh heh.
[10:58:25] <jhutz> but I more or less agree with what you describe
[10:58:40] <nico> could we have EKR3 written down?
[10:58:47] --- alexeymelnikov has left
[10:58:54] <mrex> rlbob: Trusted computing base, secure attention key -- there is a risk in the apps layer dealing with and persisting cleartext passwords, and more so if it talks to the user through easily-spoofable (G)UIs. The more people get accustomed to the current situation, the harder it will be to learn them the difference between a secure UI that is trustworthy for passwords and a applicaton gui
[10:58:56] <cat> I have: EKR3: claim & attribute transerrals
[10:59:26] <jhutz> yeah.
[11:00:06] <jhutz> EKR2 is about setting up an association with site B whose identity is based on the one you already have with site A. Essentially, you're sharing an identity across sites.
[11:00:30] --- mani has joined
[11:00:34] <jhutz> EKR3 is about site A being able to assert things about you to site B
[11:01:25] <jhutz> conceptually, it's the difference between a name or identifier and a property. one does not necessarily imply the other
[11:01:29] <marcos.sanz> Lisa adds to EKR2: "Raw assertions of identity are easier to trust than attributes"
[11:01:57] <marcos.sanz> and labels this as "Name subordination"
[11:04:13] <jhutz> Lisa is exactly right. This goes back to what ekr said earlier about multiple levels of functionality
[11:04:57] <marcos.sanz> Lisa renames EKR2 from "Cross-site identities" to "Cross-site Identifiers"
[11:05:04] <jhutz> rlbob++
[11:05:32] <mani> id provider providing an assertion is to be considered as a delegated trust of authentication (of identity) isn't it? why else would it be an id provider - when it asserts?
[11:06:10] <marcos.sanz> About 15 hands up
[11:07:01] <marcos.sanz> Lisa adds to ERK2: Probably existing technology, maybe glue work
[11:07:21] <jhutz> Do we think we're within 23 minutes of finishing?
[11:07:29] <pigdog> which is this again?
[11:07:29] <marcos.sanz> About 15 hands up again
[11:07:41] <pigdog> what are we referring to?
[11:07:54] <pigdog> what is the question?
[11:07:54] <nico> ekr2
[11:07:57] <pigdog> ok
[11:07:59] <marcos.sanz> More analysis needed? 10 poeple
[11:08:00] <mani> needs more analysis
[11:08:30] <ekr> BTW, for the distinction between cross-site identity and third party claims, I suggest the evocative term is that cross-site identities are self-validating.
[11:09:15] --- raeburn has left: Disconnected
[11:09:19] <mani> why can't they be based on delegated trust of a trust anchor - as in SAML or certs?
[11:09:49] <gregth> is a "cross-site identity" something that i make up and sites simply believe is me?
[11:09:57] --- joao@jabber.isc.org has joined
[11:10:08] <gregth> rather than something a central party (and IdP) says about me?
[11:10:11] <ekr> gregth: what she means here is that the identity is issued by one site and you leverage it to talk to others.
[11:10:11] <mrex> the currently predominant form of identity theft is phishing, because the use of disclosing (replayable) authentication schemes make it possible
[11:10:14] <nico> mani: they == ??
[11:10:18] <ben> wtf does "uplevel" mean?
[11:10:25] <ekr> uplevel==go meta.
[11:10:27] <ekr> :)
[11:10:30] <nico> mrex: not only
[11:10:45] --- joao@jabber.isc.org has left
[11:10:51] <gregth> then it's not self validating. you need to somehow verify that the issuer really issued it.
[11:10:55] <mrex> if we migrate to non-disclosing (non-replayable) authentication schemes, the bad guys are going to focus on trojans instead
[11:10:55] <mani> ekr: cross-site identity is what i meant by they - to your statement
[11:11:08] <ben> how about I just shortcut this by going postal?
[11:11:17] <nico> mrex: exactly
[11:11:20] <ben> :-P
[11:11:20] <gregth> ben: be my guest
[11:11:29] --- bhoeneis has left: Replaced by new connection
[11:11:31] <cat> ben - please :D
[11:11:35] <cat> That's always fun to watch.
[11:11:36] <nico> ben: are you physically in this room?
[11:11:44] <ben> yes
[11:11:49] <cat> nico - he's in the red shirt in the front row.
[11:11:56] --- bhoeneis has joined
[11:12:10] <nico> mani: w/o stronger http auth that would scare me
[11:12:11] <ben> and I'm not female :-)
[11:12:25] <rlbob> in my security-context, uh, context, I think the minimal security context, in the case where the user wants to access an "account" at an app many times (the common case), is an identifier that is mapped to that account
[11:12:29] <nico> ok, wait for me to leave before going postal, yeah?
[11:12:43] --- Melinda has left
[11:13:01] <pigdog> good, because i thought the two of you were going to do a blind date....
[11:13:02] <rlbob> that is useful without adding other authentication-time-provided info to the context
[11:13:11] <marcos.sanz> Lisa adds to EKR2: Requires work/solution EKR1
[11:13:52] <jhutz> "I believe that the missing link is deciding on something where everyone has to do business with me in order to talk to each other"
[11:13:53] <mani> nico: agreed. strong http-auth is implied (TLS-based, e.g.)
[11:14:05] <nico> well, that's ekr1
[11:14:08] <pigdog> ah: phb discusses something that can be correlated. this is meat but it's going to hurt.
[11:14:14] <pigdog> this is the problem with ekr23
[11:14:17] <pigdog> sorry, ekr2
[11:14:26] <nico> so working on ekr2 implies working on ekr1
[11:14:39] --- admcd has joined
[11:14:58] <marcos.sanz> Lisa adds to EKR2: May require shared mechs & Definitely requires co-ord
[11:15:01] <jhutz> What phb is talking about is not really about the link between ekr1 and ekr2; it's the link between ekr2 and ekr3, and we haven't got to ekr3
[11:15:40] <marcos.sanz> Pete: Ppl to work on EKR2 as decouple from EKR1
[11:15:42] <marcos.sanz> ?
[11:16:31] <marcos.sanz> Pete rephrases: Are you willing to work on EKR2 and 1 as separate problems?
[11:16:40] <marcos.sanz> 6 hands
[11:16:45] <mani> <raising hand>
[11:16:59] <marcos.sanz> Pete: Who thinks this would be a bad idea?
[11:17:22] <ekr> I'm only willing to work on them separately if there's no coordination.
[11:17:35] <marcos.sanz> Who thinks it is a bad idea to work on EKR2 if EKR1 never happens?
[11:17:37] <ekr> If there's coordination, I'm out.
[11:17:38] <marcos.sanz> About 10 hands
[11:17:40] <pigdog> i think i raise my hand
[11:17:46] <pigdog> i think i lower my hand
[11:18:01] <mani> <raising hand>
[11:18:03] <marcos.sanz> I missed the last question, sorry
[11:18:23] <marcos.sanz> Assuming EKR1 is finished, would you work on EKR2?
[11:18:25] <marcos.sanz> About 10 hands
[11:18:28] <mani> yes
[11:18:50] <jhutz> rlbob, the question Sam was asking was largely about whether there is a _dependency_
[11:18:51] <pigdog> obviously i want to get to EKR4...
[11:19:08] <jhutz> people who think working on ekr2 without ekr1 believes the former has a dependency on the latter
[11:19:31] <pigdog> could be the other way around
[11:19:48] <marcos.sanz> 10 minutes left
[11:19:50] <rlbob> dependency implies ordering and priority, no?
[11:19:55] <cat> ribob - no.
[11:20:08] <jhutz> no, it doesn't.
[11:20:36] <rlbob> else it implies they are the same problem, is that what you're claiming?
[11:20:37] <marcos.sanz> Lisa writes on the board: EKR3 "Claim & Attribute Transferral"
[11:21:15] <marcos.sanz> About 20 ppl who think there is already a C&A-Syntax existing
[11:21:17] <mani> <yes>
[11:21:19] <pigdog> i think this borders heavily on W3C/Liberty stuff
[11:21:20] <marcos.sanz> which can be used
[11:21:31] <marcos.sanz> Need to invent one? Nobody
[11:21:36] <pigdog> no we don't need to invent one
[11:21:45] <ekr> RFC 5752 "SAML Assertions Carried Over X.509 Attribute Certificates"
[11:21:52] <marcos.sanz> Lisa adds to EKR3: Existing c&a syntaxes can be used, maybe glue work
[11:22:31] <marcos.sanz> 8 mins left
[11:23:31] <pigdog> spoken like a true iab member
[11:24:12] <marcos.sanz> Lisa adds to EKR3: Binds Attr assertions to underlying communication
[11:24:45] <jhutz> I don't think nico and ekr were about to get into a terminology debate. I very much suspect they were going to get into a technical debate based on terminology they already agree on.
[11:24:59] --- cullenfluffyjennings@gmail.com has left
[11:25:00] <pigdog> swell
[11:25:23] <pigdog> EKR4?
[11:25:26] <nico> jhutz: yes
[11:25:41] <nico> ekr: that's your clue to say "no"
[11:25:49] <nico> ^clue^cue^
[11:25:56] <ekr> My thought was that channels make messages :)
[11:26:05] <nico> ekr: yes!
[11:26:08] <nico> :)
[11:26:17] <nico> that's an HTTP-centric view of the world
[11:26:22] <nico> and it's a-ok
[11:26:23] --- joao@jabber.isc.org has joined
[11:26:34] <jhutz> If ekr said "no", then you'd be agreeing about the answer, but disagreeing about the terminology.
[11:26:47] <marcos.sanz> Lisa adds to EKR3: Not limited to HTTP
[11:26:55] <pigdog> agree
[11:27:00] <gregth> let's keep the door open for authentication mechanisms that carry attribute information along with them. it's not always the case that the attribute information exchange comes after the user has authenticated.
[11:27:29] <marcos.sanz> Pete asks: PPl think we have work in EKR3 which is not protocol specific and we can do?
[11:27:41] <rlbob> gregth: agree, as such mechanisms are in common use already
[11:27:49] <marcos.sanz> Pete rephrases
[11:27:50] <mnot> Where's Phil's rat?
[11:28:31] <pigdog> mic: we will have lost site of the true consumer problem if we don't get to EKR4
[11:28:36] <cat> Well - there's everything from instant coffee to expresso machines involved here...
[11:28:37] --- bhoeneis has left
[11:29:24] --- mnot has left
[11:29:30] --- hartmans has left
[11:30:01] <jhutz> Yes, you've been saying for a while you want to get to EKR4. We'll get there when we're done with EKR3.
[11:30:29] <marcos.sanz> Pete: Do ppl think there is work for EKR3 in the IETF that you want to work on?
[11:30:38] <marcos.sanz> About 12 hands
[11:30:48] --- psangster has left
[11:30:57] <jhutz> Remember, the purpose of a BOF like this is to discuss potential work with an eye toward maybe creating one or more working groups.
[11:31:10] <marcos.sanz> Not work on EKR3 in the IETF? 2 /3 hands
[11:31:24] <tlr> this needs extremely careful scoping and a metric ton of liaison relationships
[11:31:28] --- nico has left
[11:31:29] <jhutz> The decision as to whether to create a WG is made by the IESG, based on large part on community input. What this phase of the meeting is about is the AD's collecting the input they need to decide where to go next.
[11:31:51] <jhutz> My guess is they need more data on EKR3 than on EKR4; I think EKR4 is likely not very controversial.
[11:32:14] <pigdog> fair point.
[11:32:39] --- fred.lefebvre has left
[11:32:40] <pigdog> i agree with that statement
[11:32:44] <marcos.sanz> Half of the room agree with that statement
[11:32:46] <mani> i agree
[11:33:05] <marcos.sanz> that they shouldn't be sepparate bof/wgs
[11:33:14] <marcos.sanz> for ekr1 and 2
[11:34:06] --- xmlscott has left: Logged out
[11:34:13] --- kurosaki has left
[11:34:30] <pigdog> agree with bob
[11:35:01] <jhutz> I do think EKR1 and EKR2 have strongly-related if not the same solutions.
[11:35:07] <jhutz> I don't think solutions and specs are 1:1
[11:35:11] --- miaofy has left
[11:35:12] <pigdog> jhutz: agree
[11:35:15] <cat> jhutz - agree.
[11:35:38] <marcos.sanz> More important EKR1 than EKR2? About 15 ppl
[11:35:39] <pigdog> agre
[11:35:50] <marcos.sanz> The other way round? nobody
[11:36:02] --- leslie@ecotroph.net has left: Logged out
[11:36:38] --- Peter Koch has left
[11:37:04] <mani> we sure need to discuss more - before jumping to conclude ekr1 is enough or implies solving ekr2
[11:37:33] <pigdog> and now we've come full circle, back to naming this stuff
[11:37:40] <marcos.sanz> No hands up about issues overlooked
[11:37:47] --- kdz has left
[11:37:55] <pigdog> mic: what's the disposition of EKR4, then?
[11:37:59] --- admcd has left
[11:38:20] <marcos.sanz> Tlr speaking at the mic
[11:38:51] --- cabo has joined
[11:39:17] <tlr> tlr: try to figure out what use-cases people really want to address under EKR3
[11:39:20] <marcos.sanz> Who thinks there will be a followup of EKR3? About 15 ppl
[11:39:21] <rlbob> i think people regard EKR4 as having to wait until previous EKRs are better gelled
[11:39:30] <marcos.sanz> There wont' be a followup? nobody
[11:39:38] <pigdog> thank you!
[11:39:53] --- fparent@jabber.org has left
[11:40:40] <pigdog> we just lost audio
[11:40:54] <rlbob> servers maybe are being turned off, as IETF is over?
[11:40:56] <cat> It's 10 minutes past when we should have stopped.
[11:40:57] <pigdog> thanks everyone. see you all in san diego and online
[11:41:04] --- jhutz has left
[11:41:12] <marcos.sanz> Pete sums up
[11:41:12] <cat> pigdog - say 'hi' to Christine as well.
[11:41:19] <pigdog> will!
[11:41:21] <marcos.sanz> And announces therer will be follo ups
[11:41:30] --- rlbob has left
[11:41:36] --- pigdog has left
[11:41:44] --- robyates has left
[11:41:52] --- mani has left
[11:42:18] <marcos.sanz> Pete closes up
[11:42:22] --- gregth has left
[11:42:33] --- cat has left: Disconnected
[11:42:33] <marcos.sanz> He thanks all, we have accomplished sth today.
[11:42:37] --- dblacka has left
[11:42:41] <marcos.sanz> Adjourn.
[11:42:46] --- Jeffrey Altman has left
[11:42:47] --- marcos.sanz has left
[11:42:48] --- tlyu has left: Disconnected
[11:42:52] --- roland has left
[11:42:53] --- joao@jabber.isc.org has left
[11:43:06] --- Lisa has left: Logged out
[11:43:13] --- ben has left: Logged out
[11:45:29] --- ryu.inada has left
[11:45:41] --- JeffH has left: Logged out
[11:48:10] --- resnick has left
[11:48:50] --- geoff has left
[11:49:31] --- ryu.inada has joined
[11:49:46] --- mrex has left
[11:50:09] --- ldondeti has left
[11:50:14] --- cabo has left: Replaced by new connection
[11:59:29] --- ryu.inada has left
[12:00:05] --- dumdidum has left
[12:01:26] --- Eliot has joined
[12:01:42] --- tlr has left
[12:03:43] --- Eliot has left: Logged out
[12:06:10] --- sayrer has joined
[12:06:28] --- sayrer has left
[12:19:06] --- ekr has left
[12:35:13] --- tonyhansen has left
[19:26:28] --- ryu.inada has joined
[23:25:20] --- ryu.inada has left