[09:36:55] --- pbh has joined
[09:37:34] --- pbh has left
[12:11:28] --- mrex has joined
[12:27:25] --- Simon Josefsson has joined
[15:43:03] --- nico has joined
[15:50:38] --- raeburn has joined
[16:03:16] --- tlyu@jis.mit.edu has joined
[16:03:17] --- ms has joined
[16:05:36] --- leifj has joined
[16:05:47] <nico> no audio
[16:05:56] <nico> ...
[16:05:57] --- kdz has joined
[16:06:23] --- nov has joined
[16:06:29] <Simon Josefsson> audio works fine here
[16:06:59] --- hartmans2 has joined
[16:07:32] --- nov has left
[16:07:42] <hartmans2> test
[16:08:00] <nico> we see you
[16:08:14] <nico> simon: are you physically there?
[16:08:23] <nico> :)
[16:08:25] --- hartmans has joined
[16:08:37] <hartmans2> But we do do APIs
[16:08:54] <nico> riddle me this folks: why is uoregon.edu streaming the IETF audio instead of the IETF?
[16:09:07] <Simon Josefsson> nico: no
[16:09:12] <nico> sam: indeed
[16:09:19] <kdz> Because they know what they are doing
[16:09:48] <nico> kdz: evidently not
[16:10:01] <leifj> we believe it is just you nico
[16:11:36] <nico> ]% wget http://tinder.uoregon.edu:8000/ietf672.mp3 --15:05:49-- http://tinder.uoregon.edu:8000/ietf672.mp3 => `ietf672.mp3' Resolving tinder.uoregon.edu... failed: node name or service name not known.
[16:11:41] <nico> no, it's not
[16:11:43] <leifj> Jhutz is polling the room for info about who has read what
[16:11:51] <nico> http://videolab.uoregon.edu/events/ietf/
[16:12:11] <nico> links to http://videolab.uoregon.edu/events/ietf/ietf672.m3u for the krb-wg room (Seabreeze)
[16:12:22] <nico> that contains this
[16:12:28] <Simon Josefsson> tinder.uoregon.edu has address 128.223.162.60
[16:12:32] <nico> % cat /tmp/ietf672.m3u http://tinder.uoregon.edu:8000/ietf672.mp3
[16:12:33] --- ietf-meeting has joined
[16:12:50] <nico> argh
[16:12:57] <nico> sorry, I used the wrong window for that wget
[16:13:14] <leifj> nico: you are now up on the projector
[16:13:23] <nico> really? that's fun
[16:13:30] <leifj> Jhutz does document status
[16:14:19] <nico> I'll try a computer that's directly on the 'net
[16:14:31] <leifj> Jhutz announces intention to do a wglc for a few docs (see slides) next week
[16:14:46] <nico> I did that yesterday too and many times the audio dropped; client OS/app made no diff
[16:16:49] <leifj> Jhutz admonishes people not to point mikes at the ceiling
[16:17:40] <mrex> audio is great in this room loud and clear (but close to feedback)!
[16:17:51] <kdz> audio works for me
[16:18:36] <hartmans2> Kurt, what session are you in?
[16:19:08] <leifj> JHutz sais pkinit hash agility needs review
[16:19:45] <leifj> JHutz has lost a slide from Love here
[16:20:09] <leifj> people are trying to put Loves lost slide on the projector but failing
[16:22:20] --- jhutz has joined
[16:22:54] <leifj> JHutz goes through related work
[16:23:56] <leifj> Love talks about pk-init-alg-agility -01 and -02
[16:24:10] <nico> ok, audio works now; I think my proxies are not liking me today
[16:24:28] <kdz> Sam: Seabreeze... http://videolab.uoregon.edu/events/ietf/ietf672.m3u the lag is bad, but the audio quality is fine.
[16:25:28] <jhutz> martin: sorry about the feedback; usually I tweak the mic levels before a session starts, but had no time this time. We'll try to get it better before kitten
[16:25:44] <leifj> Love asks for review
[16:27:19] <leifj> Larry and Love discussing details about the draft
[16:28:30] <hartmans2> the anonymous draft also seems to change the pkinit structures
[16:29:18] <leifj> JHutz reviewing proposed work
[16:29:33] <leifj> will discuss this at the charter discussion later on
[16:30:15] <leifj> JHutz annonces the start of technical discussion starting with Tom on extensions
[16:30:38] --- lha has joined
[16:30:55] <nico> http://130.129.2.13:8000/ietf672.mp3 worked through my proxies -- the videolab.uoregon.edu link didn't
[16:31:12] <nico> the sound drops off sometimes
[16:31:38] <leifj> Tom reviewing 1510ter goals and open issues
[16:32:05] --- stefans has joined
[16:33:31] <hartmans2> My meeting summary press release for the interim is at http://web.mit.edu/hartmans/Public/meeting-summary :-)
[16:33:57] <leifj> Tom reviewing Goals (see slides)
[16:34:35] --- nov has joined
[16:36:15] --- Jeffrey Altman has joined
[16:40:04] <nico> key exchange w/o auth is anon krb5
[16:40:10] <nico> IIRC
[16:40:43] <leifj> is it - I thought anon krb5 was auth but not identification
[16:41:21] <leifj> Tom at list of current issues with the draft
[16:41:38] <nico> same thing -- you're authenticating a name that can't be used for authorization or identification
[16:41:54] <nico> the useful thing about it is you can still setup a secure channel
[16:42:06] <nico> but I don't recall all the details
[16:42:07] <leifj> ah you had "authorization" == "auth"
[16:42:30] <leifj> usually that is "authz"
[16:42:38] <nico> no
[16:42:45] <nico> I meant auth = authentication
[16:43:29] <nico> the feedback is obnoxious :/
[16:46:02] <leifj> Tom and Larry discussing U2U (?)
[16:48:18] <mrex> Microsoft Kerberos SSP can use U2U authentication (by requesting the SESSION_KEY SSPI attribute). With Windows 2003 at Domain functional level "Windows 2003" the U2U authentication is acutally enforced by Microsoft Kerberos SSP for non-service targets
[16:48:57] <mrex> and for service-targets that never had an explicit service-principal name assigned
[16:50:15] <nico> ~
[16:50:25] <mrex> IIRC it uses a different mechanism OID on the context tokens
[16:50:49] <leifj> Tom and Larry continues discussion about the nature of MS U2U
[16:51:47] <hartmans2> I hope it uses a different oid.
[16:51:57] <jhutz> Nico, if you can give me feedback on the nature of the feedback, I will try to tweak things some more. I already turned down the level on the chair and floor mics
[16:51:57] <lha> sam: it does
[16:52:53] <nico> repeat the question
[16:53:11] --- ShoichiSakane has joined
[16:53:21] <nico> jhutz: there's these very short bits of feedback
[16:53:23] --- rlbob has joined
[16:53:37] <nico> what's the question again?
[16:53:43] <jhutz> Yeah; I just noticed some on Tom's mic, and adjusted that
[16:54:05] <nico> ah, character repertoire
[16:54:11] <nico> yes, I thought that was settled
[16:54:30] <nico> jhutz: thanks
[16:54:40] <nico> I thought we had closed this a long time ago
[16:54:52] <nico> effectively when we decided to use SASLprep
[16:56:36] <nico> ¡ interop with non-ASCII, non-UTF-8 passwords -- how's the KDC to know what non-ASCII/UTF-8 codeset/econding was used?
[16:56:45] <nico> ¡ I say tough
[16:57:17] <Jeffrey Altman> this doesn't work now if you have two different old client systems with different locales
[16:57:44] <nico> ¡ force users with such passwords to change them
[16:58:18] <nico> ¡ we're ratholing on something we've resolved in the past -- can we make progress on extensions?
[16:58:35] <nico> is this on the projector?
[16:58:56] <leifj> yes
[16:59:07] <leifj> I got jaltman to be your designated channeller
[16:59:12] <nico> ¡ ONLY to change them!
[16:59:23] <nico> ¡ But interop is already hard for such users!
[16:59:30] <mrex> this sounds more like a problem for the password changing protocol. The KDC database stores only non-ambiguous keys, doesn't it?
[16:59:45] <nico> ¡ it can't guess too well
[17:00:13] <nico> ¡ I'm multilingual -- what codeset should the realm admin guess I'd use
[17:00:40] <nico> ¡ short of me tell them? and if they'd have to ask, then force me to change the password
[17:01:03] <nico> ¡ that's right, Sam re-worked out our previous understanding
[17:01:09] --- garethdr has joined
[17:01:40] <mrex> a bit in the kdc database to hint on the string-to-key function that was originally used to create this key?
[17:02:33] <nico> mrex: whether the client that set the password knew to use SASLprep and UTF-8
[17:03:08] --- garethdr has left
[17:03:14] --- garethdr has joined
[17:03:19] <nico> ¡ my answer is yes
[17:03:51] <mrex> maybe rather add a bit to indicate the new format
[17:04:43] <nico> ¡ no
[17:04:51] <nico> ETYPE-INFO2 doesn't have a typed hole
[17:05:18] <nico> no extensibility marker
[17:05:30] <nico> ETYPE-INFO2-ENTRY ::= SEQUENCE { etype [0] Int32, salt [1] KerberosString OPTIONAL, s2kparams [2] OCTET STRING OPTIONAL }
[17:05:45] <nico> why are we talking about this?!
[17:06:07] --- Jeffrey Altman has left
[17:08:07] <nico> frankly I'd re-do pre-auth in RFC1510ter altogether, but we have to finish someday
[17:08:53] <nico> yes
[17:09:09] <raeburn> Yeah, well, I'd like to tweak some of the crypto bits in 1510ter too, but....
[17:09:16] <hartmans2> Nico, we agreed how to handle this in password, but not in the case where the new kdc has not yet seen the password.
[17:09:19] --- garethdr has left
[17:09:26] <nico> "non-preauth case: try everything"
[17:09:28] --- garethdr has joined
[17:09:45] <nico> ken: well, bring that up
[17:09:49] <nico> which crypto bits?
[17:10:14] <raeburn> It's been shot down a couple times before. :-) And lots of people want minimized differences from 1510/4120.
[17:10:28] <nico> one bit: presence absence of a trivial PA-DATA
[17:10:29] --- jaltman has joined
[17:10:32] <raeburn> Stuff like using AEAD modes where we want encrypted data plus authenticated plaintext using the same key.
[17:10:37] <nico> AEAD
[17:10:38] <nico> right
[17:11:21] --- Matt has joined
[17:13:51] <nico> locking
[17:14:01] <nico> ¡ N strikes you're locked
[17:14:04] <nico> channel me
[17:14:15] <nico> ok, don't channel me
[17:14:24] <nico> I agree, I'd rather talk about something else :)
[17:14:59] <hartmans2> I would have channel you if jeff hadn't realized it.
[17:16:18] <nico> transited field
[17:16:39] <nico> it isn't true
[17:16:44] <nico> it has issues
[17:16:46] <nico> namely
[17:16:48] <jhutz> explain
[17:16:52] <nico> yes
[17:17:04] <nico> if you transit an RFC4120 realm
[17:17:14] <nico> you can't then transit an extensions realm
[17:17:26] <nico> with non-ASCII realm name
[17:17:31] --- mg has joined
[17:18:42] <nico> we've discussed this before
[17:18:50] <nico> the issue is that the transited field is an OCTET STRING
[17:19:03] <nico> because it encodes the names of realms transited in a compressed scheme
[17:19:59] <mg> Sorry to ask what may be obvious to others, but are there kerberos realms out there who are not using ASCII or UTF-8? If this is a problem and non-UTF8 is in use, can the new clients indicate that it is a UTF8 name somehow, and let the server know based on what the client can handle, rather than guessing?
[17:20:10] <nico> mg: yes
[17:20:20] <jhutz> Yes there are
[17:20:31] <nico> mg: also there are realms using non-normalized UTF-8
[17:20:39] <nico> right
[17:20:56] <nico> sam: that's my point, some x-realm paths can become unavailable
[17:20:59] <nico> that's OK
[17:21:01] <jaltman> Windows uses non-normalized UTF-8 in 4120 style PDUs
[17:21:04] <jhutz> New clients indicate that names are utf-8 just by using new messages.
[17:21:31] <nico> as part of the compression scheme?
[17:21:32] <nico> OK
[17:21:35] <jaltman> New clients using Extensions PDUs will always use normalized UTF-8
[17:23:27] <nico> yes, you can use a 4120 ticket in 1510ter TGS-REQ
[17:23:36] <nico> the KDC can tell which it is
[17:23:59] <nico> how much time left?
[17:24:16] <Matt> 35 minutes
[17:24:48] <nico> note: you don't send a Ticket to a TGS: you send a PA-TGS-REQ containing an AP-REQ (well, there's 2nd ticket)
[17:24:53] <nico> anyways
[17:25:04] <nico> I think we never do have to send two versions of a string
[17:25:16] <nico> I think that was Sam's questions
[17:25:19] <nico> you've missed a lot
[17:25:20] <nico> :)
[17:25:29] <nico> I should have skyped in, eh?
[17:25:41] <jaltman> we don't have Skype at the moment
[17:26:01] <jaltman> if you want to have a comment read out loud preface the comment with a *Bang*
[17:26:04] <jaltman> !!!!!
[17:26:08] <jhutz> Well, I have skype, but no way to feed it into the audio, and no mic
[17:26:43] <nico> I may be lagged...
[17:26:44] <nico> my DSL just cut out for a bit
[17:27:08] <nico> I missed a minute of audio
[17:27:20] <nico> jeff: I did that a lot earlier
[17:27:30] <nico> jeff: and noone channeled me, so I gave up :/
[17:28:03] <jaltman> we channeled when the comments were not being said by someone else anyway
[17:28:08] <nico> ¡ yes, you do want to specify behaviour
[17:28:23] <nico> ¡ what about services that want to make decisions based on the transited path?
[17:28:32] <nico> ¡ will they understand ACE encoding?
[17:28:51] <nico> ¡ I do think that ACE encoding in transited field is fine
[17:29:37] <nico> or in normalization
[17:31:26] <nico> no
[17:31:31] <nico> scribing has not been enough
[17:31:42] <leifj> no sorry
[17:33:11] <nico> ¡ I support that
[17:33:25] <leifj> JHutz: how many support the use of ACE encoding while crossing 4210-islands
[17:33:37] <nico> I do want to think about the policy issue later
[17:33:37] <leifj> (hands going up)
[17:34:02] <leifj> ~7 in support
[17:34:03] <Simon Josefsson> What does ACE mean here? ToIDNA?
[17:34:07] <leifj> none opoce
[17:34:11] <jhutz> ToASCII
[17:34:13] <nico> ¡ BTW, I'm not sure I understood Sam's point about transit policy checking
[17:34:21] <nico> can Sam repeat that?
[17:34:23] <Simon Josefsson> jhutz: ok
[17:34:28] <jhutz> Well, no. What happens when you apply ToASCII on a label-by-label basis
[17:34:35] <nico> simon: yes, the IDNA ACE
[17:35:40] <nico> ok, I think I just convinced myself that there is no transited policy checking issue
[17:35:52] <leifj> JHutz asking for no-clue hands and don't care
[17:36:19] <leifj> JHutz - confirm on the mailing list
[17:36:22] <Simon Josefsson> I'd like to see more details how it would work
[17:36:30] <nico> note that when the RFC4120 realm is the end-point of then it needs to know of non-ASCII realm names in the transited path by their ACEs
[17:36:46] <nico> I believe that would be a security consideration
[17:36:50] <leifj> summary on the ACE issue: 7 support, none opose, few don't care/don't know
[17:37:28] <leifj> Tom on number assignement policies - JHutz asks Tom to propose a set of number assignement policies to the list
[17:38:58] <leifj> Charter discussion
[17:39:15] <leifj> Sam (AD) wants wg to agree on charter befor next agenda request
[17:39:27] <leifj> Show of hands for how many have read the charter email
[17:39:52] <leifj> (a fair number of hands went up)
[17:40:44] <leifj> Sam (AD) asks for show of hands for people who edit documents currently in the krb-wg
[17:41:01] <leifj> ~5 hands
[17:41:06] <jaltman> http://www3.ietf.org/proceedings/06nov/slides/krb-wg-1.pdf
[17:41:09] <mg> ~8 actually.
[17:41:15] <Simon Josefsson> (one problem with ToASCII on transited realm's is that RFC 4120 reference RFC 2253 for X.500 names, and X.500 names may have different idn properties than what IDNA was designed for)
[17:41:17] <leifj> Sam: who are willing to edit but not currently so
[17:41:58] <leifj> JHutz - including people who have brought work
[17:42:02] <leifj> ~2-3
[17:42:37] <leifj> Sam and JHutz discussion editor-load
[17:42:54] <leifj> Sam: willing to review documents
[17:42:59] <leifj> ~12
[17:43:53] <leifj> JHutz lists current work for charter update
[17:44:17] <nico> pre-auth framework
[17:44:27] <nico> was that in jhutz's list?
[17:44:37] <leifj> this list is stuff on its way to the iesg (modulo wglc)
[17:44:46] <leifj> yes
[17:44:53] <leifj> nico: yes
[17:45:32] <nico> we need to pick a direction on pre-auth work
[17:45:38] <nico> we have a multitude of choices
[17:46:09] <nico> ¡ Sam's right
[17:46:51] <leifj> Sam sais he probably (?) wants an explicit list of hw mechs
[17:46:55] <leifj> sorry
[17:46:57] <leifj> preauth mechs
[17:47:37] <leifj> Sam will talk to Russ about this
[17:48:13] <leifj> JHutz - protecting the AS exchange needs proposals and evaluations of those
[17:48:17] <nico> protecting the AS exchange and pre-auth frameworks, in some proposals, go together
[17:48:53] <leifj> JHutz - last we have the cross-realm issues
[17:50:00] <leifj> JHutz asks for additions to his TODO-list for the wg
[17:50:30] --- Simon Josefsson has left
[17:50:57] <leifj> at mic - password-less initial auth subsumed under preauth ?
[17:51:10] <leifj> JHutz seems to think "yes probably"
[17:51:38] <nico> who was just speaking?
[17:51:43] --- Simon Josefsson has joined
[17:51:52] <raeburn> Matt Crawford
[17:51:55] <nico> ah
[17:52:21] <leifj> JHutz sais there is overlap between various preauthy proposals which is one reason for doing the work
[17:52:47] <jaltman> His slides are temporarily at /afs/athena.mit.edu/user/j/a/jaltman/Public/krb-passwordless-hwauth.pdf
[17:52:53] <leifj> JHutz will send out a revised proposal for charter
[17:53:11] <leifj> goal is to get something for the IESG to chew on by January
[17:53:53] <leifj> JHutz encourages people to stay for kitten and Sam pluggs keyprov
[17:54:29] <jaltman> goto KEYPROV if you can. there is a proposal for distributing Kerberos service keys that needs input.
[17:54:30] <leifj> keyprov wants to provision (among other things) kerberos cross realm keys
[17:54:54] <Simon Josefsson> (I was disconnected..) Re the charter discussion, I'd appreciate WG review of my krb5starttls draft.
[17:54:56] <leifj> thursday morning
[17:55:23] <leifj> Simon: relayed this
[17:55:29] <Simon Josefsson> leifj: thanks!
[17:55:46] <leifj> JHutz - falls under the protecting the AS exchange bullet point
[17:56:06] <Simon Josefsson> jhutz: There are other advantages with krb5starttls than protecting the AS exchange, though.
[17:56:17] <nico> oh yes
[17:56:19] <leifj> Sam: starttls and fast together needs a good applicability statement
[17:56:25] <nico> they can totally simplify pre-auth
[17:56:27] <leifj> if both should go forward
[17:57:06] <nico> with channel binding of pre-auth to TLS you solve various problems in constructing a pre-auth framework that allows for combinations
[17:57:18] <leifj> q at mic about xrealm
[17:57:20] <nico> e.g., DCE RFC26 becomes trivial
[17:57:27] <Simon Josefsson> nico: exactly. and there are other advantages as well
[17:57:40] <leifj> JHutz closes the meeting
[17:57:43] --- leifj has left
[17:57:59] --- ms has left: Computer went to sleep
[17:58:06] --- jhutz has left
[17:58:27] --- garethdr has left
[17:59:01] --- Simon Josefsson has left
[17:59:48] --- nico has left
[18:00:54] --- nov has left
[18:01:11] --- lha has left
[18:01:19] --- rlbob has left
[18:02:57] --- mg has left
[18:03:29] --- kdz has left
[18:03:53] --- ietf-meeting has left
[18:04:45] --- raeburn has left
[18:07:14] --- stefans has left
[18:10:12] --- tlyu@jis.mit.edu has left
[18:11:16] --- jaltman has left
[18:19:56] --- Matt has left
[18:20:41] --- ShoichiSakane has left
[18:44:23] --- stefans has joined
[18:49:08] --- hartmans has left
[20:02:52] --- mrex has left
[22:42:45] --- hartmans2 has left: Disconnected
[23:01:36] --- stefans has left