[04:40:52] --- jhutz@jis.mit.edu/owl has joined
[04:56:13] --- jhutz@jis.mit.edu/owl has left: Disconnected
[04:57:13] --- jhutz@jis.mit.edu/owl has joined
[04:57:36] --- jhutz@jis.mit.edu/owl has left: Disconnected
[04:57:52] --- jhutz@jis.mit.edu/owl has joined
[05:54:04] --- jhutz@jis.mit.edu/owl has left: Disconnected
[06:28:51] --- jhutz@jis.mit.edu/owl has joined
[07:54:51] --- tobias has joined
[07:54:56] --- tobias has left
[08:01:36] --- jhutz@jis.mit.edu/owl has left: Disconnected
[08:18:14] --- jaltman has joined
[08:43:59] --- dwm has joined
[09:37:10] --- mrex has joined
[09:41:04] --- dwm has left
[09:42:05] --- dwm has joined
[09:46:13] --- Simon Josefsson has joined
[09:58:35] --- ghamlin@gmail.com has joined
[10:00:07] --- ietf-meeting has joined
[10:09:47] --- ghamlin@gmail.com has left
[10:22:03] --- tlyu@jis.mit.edu has joined
[10:25:37] --- raeburn@mit.edu has joined
[10:27:35] <hartmans@jis.mit.edu/owl> Who is dwm?
[10:28:07] --- lzhu has joined
[10:28:33] <dwm> dwm@doc.ic.ac.uk, newly-interested party.
[10:28:46] <hartmans@jis.mit.edu/owl> Welcome
[10:30:21] <mrex> to me the IPR statement from Certicom about ECC licensing is pretty heavy tobacco. Compulsory CA licensing and per-cert fees
[10:33:06] * dwm raises hand.
[10:34:27] --- jhutz@jis.mit.edu/owl has joined
[10:34:27] --- lzhu has left: Lost connection
[10:34:59] <Simon Josefsson> [is this presentation available online?]
[10:35:23] <jhutz@jis.mit.edu/owl> Not yet; hold on a moment...
[10:36:28] <jhutz@jis.mit.edu/owl> Slides are being uploaded now
[10:36:38] <dwm> Excellent, many thanks.
[10:36:51] --- paul.hoffman@gmail.com has joined
[10:38:17] <Simon Josefsson> http://www3.ietf.org/proceedings/07mar/slides/krb-wg-4.pdf
[10:38:18] <jhutz@jis.mit.edu/owl> OK; now on the IETF site
[10:38:29] <Simon Josefsson> thanks!
[10:38:49] --- paul.hoffman@gmail.com has left
[10:39:44] --- nico has joined
[10:42:36] <jhutz@jis.mit.edu/owl> So, is everyone in here either physically present or listening to the audio? Or rather, is anyone not?
[10:43:26] <Simon Josefsson> I'm listening to audio, which works fine.
[10:45:28] * dwm raises hand for 'Yes', cross-realm is interesting.
[10:49:35] <nico> yes, it is
[10:56:18] --- dwm has left
[10:57:17] <jhutz@jis.mit.edu/owl> Hm. Sam seems to be presenting at at least 0.5 ekr.
[10:57:27] <jhutz@jis.mit.edu/owl> Maybe even a little faster.
[10:58:15] <nico> heh
[10:59:20] * Simon Josefsson wonders what this pre-auth framework gives us that krb5starttls doesn't
[11:00:30] --- ShoichiSakane has joined
[11:01:06] --- lzhu has joined
[11:02:53] <mrex> I'm OK with preauth. I'm wondering how many roundtrips there are before AppData if preauth+iakerb+gssapiOverTLS is used -- and about what looks slightly like hen-and-egg with preauth using krb5starttls. :-|
[11:03:31] <mrex> (and I forgot AppServers requiring user2user auth ...)
[11:06:17] <nico> mrex: there's no infinite recursion
[11:06:30] <nico> recursion stops where you run out of credentials
[11:06:58] <tlyu@jis.mit.edu> unless you add principal registration into a preauth mechanism...
[11:07:01] <nico> and because we're talking about using one set of credentials in acquiring another there's no chicken-egg problem either
[11:07:12] <nico> even when we're using the same mechanism inside itself
[11:07:14] --- dwm has joined
[11:07:24] --- nov has joined
[11:07:27] <nico> TGS exchanges already use Kerberos to acquire Kerberos creds
[11:07:32] <nico> proving the point
[11:07:34] --- carl-ietf has joined
[11:10:39] <nico> yes, fast armors has fewer round-trips than starttls
[11:10:48] <nico> BTW, think DCE RFC 26
[11:12:04] <Simon Josefsson> do pre-auth handle lost udp packets? retransmission? etc? can't seem to locate the relevant section
[11:12:13] <nico> ha
[11:12:13] <jaltman> what slide are we on?
[11:12:18] <nico> referrals
[11:12:50] <jhutz@jis.mit.edu/owl> We are not on a slide. Sam finished with his discussion of what the preauth framework and FAST are, and we're discussing whether we want to adopt it.
[11:13:26] <jaltman> can someone update the audio stream link in the room subject?
[11:13:36] --- stefan.santesson has joined
[11:13:51] <nico> simon: I guess not -- RFC1510/4120 kerberos has no notion of request ID for handling PAs with multiple round-trips
[11:14:03] --- stefan.santesson has left
[11:14:15] <dwm> Done.
[11:14:18] --- stefan.santesson has joined
[11:14:23] <nico> as long as only one PA is used, of course, there is no issue because each PA with > 1 round-trip can handle that by itself
[11:14:36] --- stefan.santesson has left
[11:14:40] <jaltman> http://videolab.uoregon.edu/events/ietf/ietf687.m3u
[11:14:46] <jaltman> hand
[11:14:51] --- stefans has joined
[11:14:53] <nico> but if we'll combine multiple PAs, as in the PA framework, then the outer PA had better handle it
[11:15:03] <tlyu@jis.mit.edu> do we define nonces in a way that it's useful to use a request ID for preauth?
[11:15:05] <nico> else use TCP
[11:15:27] --- ddp@jabber.org has joined
[11:15:45] <Simon Josefsson> nico: does that mean the fast factor will have to specify lost packet semantics?
[11:15:46] <nico> but if use TCP w/o PA sequencing, then multiple unrelated exchanges cannot be multiplexed into one TCP connection to the KDC (which is no big deal, but I'm just sayin')
[11:15:57] <nico> simon: I guess so
[11:16:14] <nico> simon: I'm all for putting a bullet into the KDC support for UDP for new things
[11:16:16] <hartmans@jis.mit.edu/owl> On the client side yes.
[11:16:31] <Simon Josefsson> nico: ouch. there is also datagram tls...
[11:16:36] <nico> ugh
[11:16:47] <nico> yes, there is DTLS
[11:17:01] --- carl-ietf has left
[11:17:04] <nico> I say keep things simple stupid
[11:17:05] <mrex> is any of the new preauth going to work through iakerb?
[11:17:46] <Simon Josefsson> mrex: I reviewed zhu-ws-kerb ("iakerb") and I believe it could entirely be done over TLS with Stefan/MS's tls-gss stuff
[11:17:46] <jaltman> mic pleas
[11:18:17] <nico> sorry
[11:18:53] <hartmans@jis.mit.edu/owl> I believe that all this works through Larry's new iakerb. Well, preauth-fw; not sure about starttlls.
[11:18:54] <mrex> wait a minute -- starttls for preauth was for authentication of user<->KDC, while tls-gss is for authentication of user<->app
[11:19:33] <jhutz@jis.mit.edu/owl> And IAKERB is for allowing a GSS initiator to get his _initial_ credentials by having the acceptor relay his traffic to the KDC.
[11:19:43] <nico> that's an excellent selling point
[11:19:50] <nico> Larry and I talked about that last night
[11:19:57] <nico> but note, you could have a PA-TLS ...
[11:20:11] <Simon Josefsson> mrex: if the app==kdc, then it is the same
[11:20:20] <hartmans@jis.mit.edu/owl> well, pa-dtls
[11:20:26] <nico> alternatively, starttls could be made to work with IAKERB like proxies
[11:20:50] <nico> sam: DTLS isn't strictly needed, but, sure
[11:21:06] <jhutz@jis.mit.edu/owl> Well, sure, except bear in mind that with an IAKERB-like proxy, you usually have few choices about how you talk to the proxy.
[11:21:15] <nico> basically, the IAKERB proxy likes to deal directly with KDC exchange messages
[11:21:27] <nico> but it could deal in TLS ones instead when the client wants it
[11:21:44] <jaltman> STARTTLS is a cheaper faster to implement solution than FAST. That is its benefit. STARTTLS can't be used everywhere. Its just something that could be implemented ASAP for those organizations that want it. The existence of STARTTLS should not derail the work on FAST. FAST is going to take time.
[11:21:56] <nico> so, though this is a good selling point it's not as though Simon's proposal couldn't survive it
[11:22:04] <nico> jaltman: sortof
[11:22:24] <nico> jaltman: FAST leverages Kerberos, so if you have Kerberos but not TLS then FAST is easier
[11:22:36] <jhutz@jis.mit.edu/owl> So Jeff, are you arguing for doing both?
[11:22:47] <nico> OTOH, to really get its benefit you need PKINIT too
[11:23:04] <nico> so you if you have Kerberos and TLS but not PKINIT then STARTTLS is simpler to implement
[11:23:44] <jaltman> The question for START-TLS is "who would implement it?" If there are no implementors, then it should be published as informational. However, if there are implementors that would do so, then we should standardize both
[11:23:45] --- dwm has left: Lost connection
[11:24:20] <Simon Josefsson> i don't think preauth/fast solve the same things as krb5starttls.
[11:24:32] <nico> simon: I do
[11:24:40] <nico> for now
[11:25:02] <nico> an in-depth analysis could change that view
[11:25:07] --- ddp@jabber.org has left
[11:25:16] <Simon Josefsson> shishi in the latest debian release implement krb5starttls
[11:26:00] * nico agress with Leif
[11:26:08] <mrex> channel-bindings for starttls in preauth? Is that really necessary? I thought the whole idea is to protect the preauth on the wire
[11:26:38] --- dwm has joined
[11:26:51] <nico> moving the pre-auth out of Kerberos and into a generic framework like TLS and either use "external" or channel-bound PA inside the tunnel IS more elegant, architecturally than the pre-auth framework
[11:26:52] <nico> BUT
[11:27:45] <nico> it may be too late?
[11:27:54] <nico> as an implementor I'm not sure yet
[11:31:11] <nico> well, a soft dependency, not a hard hard one
[11:35:08] <mrex> What I see is that all the various technologies weldet together: Kerberos+TLS+X.509+PKI+LDAP. There probably is a Kerberos extension proposal including XML that I have overlooked
[11:35:41] <hartmans@jis.mit.edu/owl> I have not seen XML in this space.
[11:35:53] <jaltman> +SOAP
[11:36:00] <dwm> I think there might have been something relevant in WS-Trust and friends..
[11:36:07] <raeburn@mit.edu> XML-encoded ASN.1 for Kerberos?
[11:36:48] <tlyu@jis.mit.edu> XER has some issues that would cause problems for krb5
[11:37:05] --- leifj has joined
[11:37:19] <nico> mrex: heh!
[11:37:27] <nico> well, SAML uses XML
[11:37:43] <leifj> actually yes WS-Security has both GSS and Kerberos
[11:37:54] <leifj> in a very loose and non-clueful way
[11:37:58] <nico> and there's proposals to use SAML in various places, so, yes, in a way you're correct, there are relevant proposals adding XML to TLS/Kerberos/GSS/whatever
[11:38:10] <jaltman> if FAST was available today, would be care about START-TLS? My guess is 'no'
[11:38:13] <nico> raeburn: XER
[11:39:03] <nico> the reverse, PER encoded XML
[11:39:07] <jaltman> I strongly believe we need to protect ticket acquisition from attack
[11:39:11] <nico> aka FastInfoSet
[11:39:30] <nico> plus ├ža change
[11:40:06] <nico> ..
[11:40:57] <nico> leif: yes, WS-Security TC's Kerberos 5 Token Profile 1.0 or whatever it's called is kinda hard to understand and leaves me with questions that I've asked to no avail
[11:41:23] <nico> you can find my questions from quite a while back in the TC mailing list archive
[11:41:46] <nico> unless I'm missing something your description is correct
[11:42:25] <mrex> thanks to a large installed base of a particular Kerberos 5 implementation we will have to live with password-based server keys for several years to come, so yes, protection of the ticket acquisition (aka preauth) is desirable
[11:42:57] <jaltman> *hand* - hw-preauth
[11:43:23] <jaltman> in conversations with KenH. He would like to see the work continue.
[11:43:46] <jaltman> Even if there is parallel work done elsewhere. He is willing to do the work.
[11:44:20] <jaltman> From my perspective, there is a wide enough deployment in a broad enough number of organizations that hw-preauth should at the very least be documented as Informational
[11:45:37] <hartmans@jis.mit.edu/owl> As an AD, if it is going to be documented as informational, send it through rfc-editor.
[11:45:53] --- shpark has joined
[11:46:06] <mrex> btw. will the protection of the preauth include protection of the TGS_REP (which is actually the vulnerable thing when password-based keys are used)?
[11:46:09] <jaltman> OTP must have a solution in this space
[11:46:19] <mrex> -TGS_REP +AS_REP
[11:46:45] <Simon Josefsson> the onetimepad document contains a diffie-hellman negotiation, and might had been easier to specify as a FAST factor, or as a TLS extension via krb5starttls
[11:48:56] <jaltman> something in OTP space: YES
[11:49:51] <jaltman> CryptoCard is interested in working on a solution that would be standardized in the krb-wg
[11:49:52] <mrex> (sorry for my ignorance of not having read any documents in that area) under what key will the TGT be encrypted when using OTP ? or is this password + OTP preauth?
[11:50:20] <nico> simon: yes
[11:50:31] <leifj> need revision control for questions
[11:50:44] <nico> I think the general approach to this sort of thing in EAP is tunnel in TLS, no?
[11:50:44] <mrex> (actually I meant encryption of the TGT session key)
[11:50:57] <leifj> yes
[11:51:01] <nico> if so then the same approach should be leveraged here
[11:51:17] <leifj> nico : I also understood your comments that way
[11:51:32] <nico> so tunnel OTP in FAST+PKINIT (or anon PKINIT) or STARTTLS
[11:52:34] <mrex> some popular OTP schemes (like SecurID) doesn't provide sufficient entropy for encryption
[11:53:44] <nico> mrex: indeed, and those may not be able to either key the exchange nor channel bind to a tunnel, but if tunnelled then the lack of channel binding is survivable if the tunnel authenticates the AS to the client
[11:54:05] <nico> (e.g., TLS w/ server certs [and a small trust anchor set, i.e., not a browser's!])
[12:01:12] <jhutz@jis.mit.edu/owl> I don't thing starttls can be an rfc-editor submission
[12:01:42] <nico> no, we NEED rfc1510ter
[12:01:56] <nico> at the very least we need typed-holes all over
[12:02:24] <nico> the PA framework does NOT obviate that need because it does not provide alternatives
[12:04:58] <nico> at the very least we need Ticket extensions
[12:05:12] <nico> and I18N
[12:06:08] <nico> between those two you have 90% of rfc1510ter, the rest being typed-holes in places where it isn't clear we'll need them (but if we're doing that 90% we ought to do the remaining 10 also)
[12:06:34] <nico> if not doing rfc1510ter would mean not doing I18N then that is not acceptable
[12:08:03] <dwm> RFC 4559, Kerberos and HTTP is the addition of the "negotiate" authentication method to HTTP.
[12:08:15] <mrex> rfc4559 is SPNEGO-enclosed Kerberos "WWW-Authenticate: Negotiate" (IIRC)
[12:08:57] <dwm> An informational RFC titled "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows"
[12:10:56] <jhutz@jis.mit.edu/owl> > if not doing rfc1510ter would mean not doing I18N then that is not > acceptable That is my take as well
[12:11:41] <Simon Josefsson> seconded
[12:11:55] <nico> unless we somehow could come to agree that hey, just start using UTF-8 and to hell with IA5String, and we could show that the impact will be minor
[12:12:06] <nico> sometimes risking breaking things is worthwhile
[12:12:10] --- leifj has left
[12:12:18] <nico> so, if Larry has such a proposal to make then I'm open to it
[12:12:29] <Simon Josefsson> i'd really like that, if it is possible
[12:12:30] --- nico has left
[12:12:32] --- Simon Josefsson has left
[12:12:43] --- ShoichiSakane has left
[12:12:48] --- lzhu has left
[12:12:51] --- ietf-meeting has left: Disconnected
[12:12:52] --- shpark has left
[12:12:59] --- nov has left
[12:13:03] --- raeburn@mit.edu has left
[12:13:22] <mrex> I hate it when people break the installed base. Each time I install a new Linux Distro I notice that they're constantly breaking the installed (user) base.
[12:13:41] --- lzhu has joined
[12:13:43] <jaltman> if only we could stop using linux
[12:13:54] <jaltman> then perhaps they would stop breaking things
[12:14:01] <mrex> I like Linux, especially my old distros
[12:14:48] --- tlyu@jis.mit.edu has left
[12:15:43] <mrex> app-specific filename completion (and how to disable it) was a recent bash nuisance that really annoyed me
[12:24:43] --- jhutz@jis.mit.edu/owl has left: Disconnected
[12:39:06] --- stefans has left
[12:45:04] --- stefans has joined
[12:45:33] --- lzhu has left
[12:57:00] --- lzhu has joined
[12:57:26] --- lzhu has left
[13:47:53] --- mrex has left
[13:48:33] --- stefans has left
[14:03:58] --- jaltman has left
[14:06:42] --- dwm has left