[10:06:31] --- stefans has joined
[11:56:21] --- LOGGING STARTED
[14:14:35] --- jaltman has joined
[15:54:19] --- jaltman has left: Disconnected
[17:12:08] --- mrex has joined
[17:43:09] --- Simon Josefsson has joined
[18:07:04] --- mrex has left
[18:28:52] --- jaltman has joined
[18:34:10] --- ietf-meeting has joined
[18:40:30] --- mrex has joined
[18:40:44] --- tlyu has joined
[18:41:53] --- hartmans@jis.mit.edu/owl has joined
[18:44:35] --- ShoichiSakane has joined
[18:45:03] --- lzhu has joined
[18:45:17] --- semery@jis.mit.edu has joined
[18:49:19] --- raeburn☺ has joined
[18:50:58] --- nico has joined
[18:51:53] --- jhutz has joined
[18:59:12] --- rlbob has joined
[19:02:16] --- finn- has joined
[19:02:48] <Simon Josefsson> it is basically done, yes. there has been a few minor discussions that may lead to new text, e.g., channel binding additions
[19:02:50] <jhutz> can you hear us simon?
[19:03:20] <Simon Josefsson> although i would prefer to defer those to later
[19:03:31] --- lha has joined
[19:03:40] <Simon Josefsson> it is not clear that they are needed now
[19:04:15] <Simon Josefsson> btw, the channel binding discussions were during some earlier ietf meeting.
[19:05:02] <Simon Josefsson> they should be recorded in jabber logs or audo recordings
[19:05:33] <jhutz> channel bindings as they relate to kerberos-starttls?
[19:05:51] <jhutz> if they occurred during one of the last few meetings, there should be good audio recordings.
[19:08:52] <mrex> if you want interoperability on the request level, plain english language might be insufficient :)
[19:09:41] <Simon Josefsson> jhutz: yup. if i recall correctly, there was an idea of binding the kdc-req/rep to the particular tls channel through a channel binding. as far as i can tell, that can be done later on.
[19:10:25] <Simon Josefsson> jhutz: although the reason for doing that eludes me now
[19:11:21] <mrex> mean question: will it cover pre-utf8 implementations?
[19:11:52] <jaltman> how about German?
[19:12:22] --- shpark has joined
[19:12:47] <mrex> for interoperability with humans, an english language spec might be sufficient, but I would assume that people want to program client software to interoperate ?
[19:13:15] <hartmans@jis.mit.edu/owl> Martin that's why we take this and then develop an ldap schema
[19:13:52] <jhutz> Note that this is a data model document; it does not describe a protocol of any kind.
[19:15:30] <mrex> I have zero experience with LDAP, so I don't know whether there are two seperate approaches possible: standardizing the data model and representation (and leave requests up to creativity) or standardizing requests and leaving the data model and representation up to the creativity of implementors
[19:16:20] <hartmans@jis.mit.edu/owl> The schema we're talking about is a standardized data model using a formal language
[19:16:46] <hartmans@jis.mit.edu/owl> We also want a human readable version of the data model
[19:17:36] --- Simon Josefsson has left: Replaced by new connection
[19:18:37] <jhutz> This document is an attempt to standardize a data model for the KDC. It will be followed up by another, separate document which specifies an LDAP schema. We have not yet started work on the latter document.
[19:18:45] <mrex> is there a formal language that is easy to understand, or preferably, one that is already common in IETF specs?
[19:20:20] --- Simon Josefsson has joined
[19:21:02] <mrex> yup, we need to keep in mind that we want to finally have independent interoperable implementations
[19:25:46] <mrex> can all Kerberos administrative task be performed centrally?
[19:25:52] <Simon Josefsson> i'd prefer the data-model is standalone from the ldap schema. i'm basing my management system on leif's data model, but i'm not supporting (or planning to support( ldap
[19:26:12] <mrex> what about distribution of service keys to services?
[19:26:52] <Simon Josefsson> overlap with keyprov?
[19:27:51] <mrex> or kerberos configuration (servers/services/clients) to machines? Part of the Kerberos administrative tasks is bootstrapping
[19:29:36] --- bnsmith has joined
[19:29:54] <mrex> if you talk about managing the kerberos protocol, what kind of "management operations" are in scope? which are standardized at all?
[19:30:19] <lha> so far we are talking about the datamodel that the KDC is using
[19:30:34] <lha> so it can be mapped to external protocols, like ldap, soap, etc
[19:35:15] <mrex> in the past, recurring Kerberos maintenance could make use of its own infrastructure (krcp,ktelnet,krsh). Looking ahead, Kerberos will need LDAP and TLS to perform its management tasks... :-|
[19:36:13] <nico> mrex: krcp, ktelnet, krsh are not Kerberos protocols
[19:36:36] <nico> they are non-Kerberos protocols that have been modified to know how to use Kerberos
[19:36:58] <nico> and the same is true of LDAP (SASL/GSSAPI and, soon, SASL/GS2/Kerberos mech)
[19:37:14] <nico> and even TLS (RFC2712, but let's not talk about _that_)
[19:39:00] <nico> (and it's true of ssh, which we should be telling everyone to use instead of krsh/krlogin/... :)
[19:42:29] <lha> mrex: if the data model describes what operations and how that modifies that data, when writing a protocol to access the data (using ldap or something else) all infomration needed for the operaiton is avaible
[19:43:06] <mrex> nico: if a large number of protocols use LDAP and tls for management stuff, then there is some synergy and code-sharing at least
[19:43:32] <nico> well, ssh is huge but there's not an ounce of krb5 code in it
[19:43:49] <nico> that's the point of using frameworks like the GSS-API
[19:52:31] <mrex> asking for being able to centrally design and store UI (texts) on the KDC and have them configurable by the customer and means to display them in a standardized way on clients
[19:52:45] --- shpark has left
[19:54:13] <mrex> having to solve localization for each and every component individually is a lot of work, and likely to be inconsistent depending on size of infrastructure and number of different providers/vendors
[19:55:31] <mrex> being able to provide a centalized localization through the KDC is in some way appealing.
[19:57:35] --- lha has left
[19:58:50] <nico> mrex: we agree!
[19:58:52] <nico> :)
[19:58:57] <mrex> be careful to overload semantics (worst conceivable scenario: active content) when distributing localized (error) messages that can not be authenticated. :)
[19:59:08] <mrex> +not
[19:59:25] <nico> the set/change pw protocol I-D that is currently broken (formatting) actually provides for KDC-side localization
[20:00:02] --- finn- has left
[20:00:03] <nico> the client says "I speak these languages" and the KDC picks one to localize password quality policies to
[20:01:18] <mrex> KDC sends HTML-formatted localized error messages and client allows active scripting... that sounds dangerous
[20:01:20] --- lha has joined
[20:01:38] <nico> who wants that?
[20:01:59] <nico> (but then, that's how the web works)
[20:02:15] <lha> mmmm auto-upgrading clients
[20:02:26] <nico> lha: for example
[20:02:30] <nico> there are others
[20:02:36] <mrex> do you think that XML in face of the recent XSLT remote vulnerabilites is any better?
[20:03:05] <nico> noone is proposing any markup in this context
[20:03:42] <nico> not Sam, not I
[20:03:56] <nico> OTOH, that might be a way to solve the UI issues! :)
[20:04:22] <lha> clearly we need to define a asn.1 scripting languge to be feature complete with XML :)
[20:04:30] <nico> it's called SDL
[20:09:25] --- finn- has joined
[20:09:34] <lha> cool, but not really what I wanted, more javascript like and/or xslt like
[20:09:50] <mrex> I'm sorry for mocking
[20:10:10] --- Simon Josefsson has left
[20:10:17] <mrex> no, seriously, I think that localization of (error) message through KDC has value
[20:10:32] <lha> you are very serious sounding when mocking
[20:10:56] <lha> martin: yes it does but have nothing todo with the FAST as it is
[20:11:35] <nico> mrex: and that is what the set/change password protocol provides for; since FAST won't have keyboard-interactive/PAM-like prompting it won't need to do localization
[20:12:14] <nico> that said, in the past we've agreed to extend the KDC-REQ (in rfc1510ter) to allow the client to send a list of language tags it understands, for localization of things like KRB-ERROR
[20:12:19] <jaltman> !!!! speak up at the mic please
[20:12:59] <nico> jeff: is that OK?
[20:13:09] <jaltman> much better, thank you
[20:13:21] <jaltman> (there is a delay of at least 10 seconds)
[20:16:42] <nico> I wouldn't say that's a lack of PFS problem (though adding PFS would help)
[20:23:55] <jaltman> and look at the waiting times
[20:24:23] <jaltman> I'm more concerned about the waiting times than the cpu usage
[20:25:03] <nico> yes, length of trust chain, and consequent number of synchronous DNS SRV RR lookups + TGS exchanges is the problem
[20:25:09] <jaltman> how likely is it that the network round trip times will improve?
[20:25:29] <mrex> the bandwidth and size of message is often more of a problem than cpu horsepower, e.g. for RSA-SmartCards the serial interface is the bottleneck, and the RSA chip on the card can't beat the PC because of this
[20:25:38] <nico> the crypto is incidental, though for those devices today it be a significant incidental
[20:26:04] <nico> mrex: even for USB?!
[20:26:20] <mrex> It is the interface on the smardcard chip, not on the reader
[20:26:24] <jaltman> 294ms of cpu time is inconsequential when compared to the 4500ms time for ticket acquisition due to network delays
[20:27:54] <mrex> a few years ago I compared an SSL-stack with NCipher SCSI cryptobox using RSA-smartcards against pure-software SSL, and the results looked bad for the NCipher box
[20:29:39] <mrex> it was significantly faster than an older dual-core UltraSparc, but it had difficulties keeping up with a dual-Xeon PC running Linux
[20:32:13] <nico> mrex: total throughput might be different -- a crypto co-processor may have high latency but high throughput, which means that if serve lots of clients then it helps, but for single-thread perf it may suck
[20:32:49] <nico> (though that may not be the case for the HW you have)
[20:32:56] <nico> ^may^might
[20:35:44] <mrex> well, if you have a long list of trusted independent CAs (such as a Web-Browser) then one only needs to corrupt one of the CAs to break your security if your verification only checks where a certification path ends at one of your configured trust anchors. Of course, by using PKI technology you have the advantage that not all of the involved third parties get knowledge of your session keys (because these KDCs create/issue those session keys).
[20:36:40] <nico> presumably most PKINIT and PKCROSS deployments will have short PK trust chains
[20:38:06] <nico> (or, at least, the total length of PKI and krb5 CA/transit path will not grow too much as a result of deploying PKINIT/PKCROSS
[20:40:07] --- jaltman has left: Disconnected
[20:42:06] --- lzhu has left
[20:42:16] --- tlyu has left
[20:42:23] --- ShoichiSakane has left
[20:42:58] --- raeburn☺ has left: Logged out
[20:43:23] --- ietf-meeting has left: Disconnected
[20:43:44] --- nico has left: Disconnected
[20:44:06] --- rlbob has left
[20:44:51] --- mrex has left: Replaced by new connection
[20:46:23] --- mrex has joined
[20:46:36] --- finn- has left
[20:47:27] --- jhutz has left: Disconnected
[20:47:39] --- semery@jis.mit.edu has left: Disconnected
[20:48:33] --- mrex has left
[20:53:01] --- lha has left