[00:08:01] --- wyllys has joined [00:11:07] --- wyllys has left [00:16:30] --- wyllys has joined [00:16:36] --- wyllys has left [11:06:26] --- wyllys has joined [11:06:29] --- wyllys has left [11:12:47] --- wyllys has joined [12:49:59] --- wyllys has left [13:10:31] --- jas has joined [14:14:51] --- hartmans has joined [14:18:49] --- kenh has joined [14:33:57] --- jaltman has joined [14:38:12] --- warlord has joined [14:38:27] --- tlyu has joined [14:39:38] --- DougEngert has joined [14:40:41] --- leifj has joined [14:41:38] --- leifj has left [14:42:07] --- leifj has joined [14:43:01] --- raeburn has joined [14:43:05] --- lha has joined [14:45:18] --- jhutz has joined [14:49:00] --- krb-wg has joined [14:49:04] Doug Engert is opening the meeting. [14:49:06] --- pbh has joined [14:49:15] Pre-meeting discussion suggests that we may be able to require DER for CMS, but their may be problems with certs. [14:49:22] Passing of blue sheets, etc. [14:49:53] Especially when directories are involved; they tend to produce BER encodings of certs. [14:49:59] (Any notes other than the jabber scribe are welcome) [14:50:52] so signature verification involves decoding and re-encoding; collective groan followed [14:50:54] http://grand.central.org/dl/ietf-krb-wg/ [14:51:01] encryptedContent when doing encryptedData is a problem [14:51:05] --- masahiro has joined [14:52:05] welcome to the 59th IETF [14:52:21] some implementation does BER encoding of the OCTET STRING for streaming reasons, and then part of the data is BER and part DER [14:52:27] Agenda bashing ... very quickly. [14:52:51] (Note: bulk of time will be spent on pkinit) [14:53:00] --- wyllys has joined [14:53:56] note: jhutz has a crappy laptop and it doesn't display the agenda properly. [14:54:33] according to Russ, some X.500 directories accept a certificate in DER and re-encode it in BER and then send the BER encoded version when a certificate is requested from the directory. The recipient must decode the BER and re-encode as DER before verifying the signatures. Implementations which do not support both BER and DER will be *surprised*. [14:55:08] First topic: Document status [14:55:23] Crypto Framework: RFC Editor Queue [14:55:24] pwd [14:55:41] am I showing up here? [14:55:46] Yes. [14:55:50] who are you? [14:55:54] as nico-sun? [14:56:00] as krb-wg [14:56:02] no, as krb-wg [14:56:02] Loe, do you object to the PRF change? I assume you have actually implemented. [14:56:12] why? how to fix? [14:56:25] --- krb-wg is now known as nico-sun [14:56:34] ok, got it [14:56:41] (sigh) [14:56:52] hartmans: PRF change is just fine, implemented but not deployed so it doesn't matter [14:56:58] sam speaks to prf [14:57:55] Sam Hartmans: We try to avoid using keys directly, and instead we want to derive keys for each use. We didn't do this for PRF. We want to change this. Basically, instead of using the protocol key directly, you call DK() on the key with a fixed constant (which we need to decide on). One line document change.\ [14:58:47] Number of votes for this change, nobody opposed. [14:59:06] Next Topic: GSSAPI-CFX: RFC Editor Queue [14:59:58] Steve Bellovin said he was unsure with Sam's assertion that no registries are needed, still outstanding. [15:00:09] Next topic: AES [15:00:26] Still in IESG queue. [15:01:01] Ken raeburn: Comments from last-call process: some of the recommendations were vague (e.g., key salting recommendations) [15:01:15] Russs Housley: AD's haven't decided on it yet. [15:02:48] Next topic: Clarifications [15:03:06] pepole are playing around with the projector here.... [15:03:43] Status: One more revision to go. [15:04:34] Issue from Steve Bellovin regarding link-local addresses; discussed with ADs in the Internet area, believe it is resolved. [15:05:33] Cliff Neuman will put out a set of changes. [15:06:06] Another issue on mailing list: Requests from Nico Williams & Wyllys Ingersoll to add AES-128 enctype to clarifications. [15:06:20] as recommended [15:06:33] --- amelnikov has joined [15:06:36] (SHOULD) [15:06:45] If there are no objections, they will be added for next revision. [15:07:05] Next topic: WG Priorities [15:07:35] Going through WG milestones and seeing if they still apply. [15:08:47] (First milestone should be "Clarifications", not extensions). [15:09:11] --- wyllys has left [15:09:18] First draft of pre-auth framework issued, should be complete in Jan 05. [15:09:47] First draft of extensions: Document should be complete by Washington. [15:10:40] Need to adjust time for PKINIT milestone. [15:11:16] Adjust extensions document submission to IESG to April 05 [15:12:03] Holding off on set/change password milestone date for now. [15:12:29] we'll talk about the date after my presentation on set-passwd v2 [15:13:27] Suggestion for pre-auth framework milestone for Jan 05; still undecided. [15:13:39] Sugggestion to drop milestone for PKCROSS because it's too far out. [15:14:20] Russ points out that if a document is listed in the charters, it neeeds to be on the milestones. [15:15:22] There doesn't seem to be a charter listed on the web page for krb-wg; will have to defer discussion on PKCROSS. [15:15:37] --- wyllys has joined [15:15:50] Final item: Milestone review. We're ahead on this one. [15:16:05] Next Topic: PKINIT, Brian Tung speaking. [15:16:31] Major issues (culled by Jhutz from the mailing list) [15:17:08] OCSP and optional revocation info: Should we merge spec into PKINIT or submit as separate draft? [15:17:28] Brian: Thought Nico and Larry were in agreement. [15:18:13] Nico: Only objection right now is where OCSP [15:18:18] --- amelnikov has left: Replaced by new connection [15:18:19] --- amelnikov has joined [15:18:19] --- amelnikov has left [15:18:23] ... where OCSP info goes. [15:19:12] separate PA, separate I-D [15:19:23] the end [15:19:34] DH Key derivation [15:20:42] Sam: What we're trying to do is that several parties want to be able cache a DH key for several hours and use it again in static-static mode. [15:21:03] Sam: Main issue is how we do key derivation and how we use nonces. [15:23:10] New proposal: Add nonces both directions, DH-specific nonces, longer than clarifications nonces, You will have to omit the nonces in the signed data using this mode. You then take a bunch of stuff and in the packet and feed it into PRF. [15:23:55] This requires a wire format change; I believe we should defer the discussion until we see if we have other wire format changes. [15:24:04] I don't see any real problem with changing the wire format, the server is aware of old/new client via PA number [15:24:05] --- jaltman has left: Replaced by new connection [15:24:05] --- jaltman has joined [15:24:05] --- jaltman has left [15:24:16] Consensus of room is that we should do it. [15:25:33] --- amelnikov has joined [15:25:38] (The whole issue of wire format changes will be deferred to the list) [15:26:31] (the question of MAY versus SHOULD will also be deferred to the list) [15:26:45] Next subtopic: DER versus BER. [15:27:54] DAP does the evil thing [15:28:18] the evil thing being: decode, re-encode using different rules, which breaks the sig [15:28:41] but that's ok cause the peer decodes, re-encodes and verifies the signature [15:28:50] encryptedContent when doing encryptedData is a problem, some implementations will encode the encryptedData in BER so they can stream data into the object regardless if it knows the length of the inline data or not [15:29:03] Russ: When a CA makes a certificate, it encodes it in DER. When the cert is placed in a X.500 directory, the protocol that you talk to the X.500 directory (DAP) doesn't use an octet-string for the cert, but the ASN.1 structure of the cert. [15:29:15] evil indeed [15:29:35] Russ: And the directory will encode the cert in BER, so clients need to be able to decode and reencode it in DER. [15:30:03] example: http://people.su.se/~lha/patches/heimdal/pkinit-needs-octet-string-wrapping.txt [15:31:31] lha, is there a hexdump of that encoding? [15:31:47] --- jaltman has joined [15:32:00] jhutz: We'd like to specify one encoding, and we'd like it to be DER. [15:32:28] tlyu: replace txt with raw and you the the binary blob [15:32:34] sam: I'd like to object to picking DER. It seems like we're doing this for one vendor which didn't support indefinite-length encodings. [15:34:46] tlyu: My experience is that going from a hand-coded DER encoder/decoder to a general-purpose BER encoder is hard. [15:35:12] I don't mind picking DER, but I think its wrong and we couldn't do it (I voiced this concern in ietf-58, so its not like you had warning) [15:35:43] lha: I just offered a straw man: specify BER for the PKINIT types [15:35:45] :) [15:36:24] jhutz: I'll channel some stuff from CableLabs: They believe that permitting BER is a significant change in the spec, and they will choose to be non-compliant in this respect. They won't like it, but that's what they will choose to do. [15:37:55] sam: The assumption is that we would like to make life easier for one vendor by specifying DER. But we're also making life easier for another vendor by spec'ing BER. [15:38:33] sam: When picking a vendor to make life easier, we should pick a vendor who is operating on the open internet, and not one in a walled garden. [15:39:17] Its a CMS type, we can't choose, its BER. so the question is if we should allow BER in kerberos spec or wrap it with OCTET STRING [15:39:26] does Heimdal use its own CMS implementation? [15:39:33] or does it use OpenSSL [15:40:11] Leif says it uses its own [15:40:57] heimdal have code that three versions of it, valicert, openssl, heimdal. the first two requires me to use something of the equvalent of ANY [15:41:33] IOS [15:41:44] Information Object System [15:41:47] :) [15:42:03] jhutz: Channeling cablelabs again: Wrapping CMS in octet string isn't harder, but it will be a protocol format. [15:42:32] heimdal's asn1 parser/generator only support enough BER to work with DCE [15:42:56] --- N7DR has joined [15:43:51] jhutz: Wrapping helps some vendors seperate from the encoding issue. [15:45:40] jhutz: Note that wrapping is not intended to solve the DER versus BER issue; it's to solve the issue of "I want to use a CMS library to parse certificates" issue. [15:46:32] jhutz: Does using IMPLICIT OCTET STRING avoid a change to the on-the-wire protocol? [15:46:43] tlyu: No, it does not avoid a change. [15:47:12] tlyu: it's a one-bit change to the on-wire protocol. [15:49:03] --- Kurt has joined [15:49:42] Consensus of the room is that we want to wrap it with OCTET-STRING. Are there objections on jabber? [15:50:01] IMPLICIT OCTET STRING [15:50:19] hey, nico, you're welcome to take over scribe if you want :-) [15:50:47] was it Implicit or Explicit? I thought Explicit [15:51:13] explicit has bigger on-wire change; implicit is the one-bit change. [15:51:52] Not much in it really; they are both changes, but noth are small changes, aren't they? [15:52:08] FWIW, I gneerally prefer EXPLICIT wherever possible [15:52:26] warlord: implicit [15:52:47] ok, that seemed unclear [15:52:53] (to me) [15:53:21] jhutz is being especially grumpy right now. [15:53:27] does the room agree with me? [15:53:34] I owuld like ot echo the earlier comment about the difficulty of converting from a hand DER encoder/decoder to a general BER one; it's a rather difficult change [15:53:39] --- pbh has left: Replaced by new connection [15:53:39] --- pbh has joined [15:53:39] --- pbh has left [15:53:52] --- pbh has joined [15:54:35] My experience with people who are new to ASN.1 encoded messages are much more likely to get EXPLICIT right than they are to get IMPLICIT right [15:54:37] MS uses IMPLICIT OCTET STRING to wrap all CMS types [15:54:58] Yeah, this is tough. We're basically chosing between simplicity and supporting all off the shelf CMS encoders [15:55:37] Well, if you prefer explicit tags bring that up on the list. [15:55:46] I think the rest of us don't care so much [15:56:49] I really don't care; rmemeber though that I have been through the experience of watching a new industry suddenly having to implement ASN.1 messages, and most of them get IMPLICIT stuff wrong at first. So that's where I'm coming from. [15:57:42] we're moving to unauth plaintext issues [15:57:49] jhutz: There is no clear consensus on whether we should permit PKINIT implementations to reject BER-encoded certs; taken to list. [15:58:06] sam is not confident that there is no unauth plaintext issue [15:58:23] kenh: maybe we should scribe different participants :_ [15:58:26] :) [15:58:41] --- larry has joined [15:58:52] sam: unsure if there are security issues with unsigned parts of the protocol. [15:59:03] (nico, you can take sam for the rest) [15:59:13] I don't understand why there are unsigned parts of the messages at all ? [15:59:13] Now on to nonces [15:59:29] lha: want us to mention this? [15:59:34] why isn't all data inside the AuthPack ? [15:59:45] jaltman offered to review the document for security issues. [16:00:02] lha: we're not going to resolve that ehre [16:00:05] Because pkinit sucks? [16:00:09] jhutz: You should ask that on the list. [16:00:12] FYI, Eric is going to try to join in a few minutes. We are both in a different meeting here :-) [16:00:15] someone will be tasked with looking at that and reporting to the list [16:00:17] And because you explicitly want it for static-static dh [16:00:44] --- Eric Rosenfeld has joined [16:01:29] hartmans: because pkinit needs to be rewritten from scratch now that we know what's broken ? [16:01:40] I need a beer :-) [16:02:02] (B) [16:02:15] tlyu: FYI: nonce is not a named type in clarifications, but it is constrained. [16:02:19] PKINIT nonces: same as clarif? or some octet string of, say, fixed size? [16:02:32] correction: microseconds is constrained. [16:02:38] I've always supported a rewrite of pkinit from scratch; I realize it is not politically possible [16:03:23] jhutz: We could have Extensions patch PKINIT, but I'm not sure we want to. [16:03:48] --- leifj has left [16:03:51] now, why do pkinit have nonce ? it have a checksum of the request nonce... [16:03:55] moving this to the list [16:03:58] --- leifj has joined [16:04:03] static-static dh [16:04:35] love's reply enc key issue to the list [16:04:58] now onto DH groups issue [16:05:09] jhutz: Russ, will the IESG approve a document where we recommend the use of DH using Oakley groups 1 & 2 only? [16:05:15] Russ: maybe. [16:05:35] jhutz: Based on recent experience with ssh, I would say no. [16:06:12] But can't we jusyt say "one of the groupos from RFC xxx and yyy"? [16:06:17] PKINIT already has group negotiation? [16:06:22] jhustz says so [16:06:32] encKey was dropped from the spec [16:06:43] Yes it has negotiation; I think this may be less of an issue that jhutz claims [16:06:43] Doc: The issue is that we now say RFC 2409, and should we change to RFC 3526. [16:06:52] do: must have one MUST [16:06:52] Can;t we include both, though [16:07:00] we can have more than one MUS [16:07:20] MUST [16:07:23] Obviously, our implementations all require 2409 [16:07:30] russ: must have at least one MUST DH group [16:07:40] currently groups 1&2 are SHOULDs [16:08:00] so is what russ just said true? [16:08:07] Do we have to have a MUST? [16:08:16] doc: Yes. [16:08:16] What's wrong with SHOULD? [16:08:21] MUST group 2 and negotiate others is ok [16:08:26] doc, it's an interop issue, i think [16:08:27] You need one MUST for interoperability. [16:08:29] no need to MUST group 14 [16:08:32] says russ [16:08:37] How do you negotiate? [16:08:41] dunno [16:08:58] I think the only way is with a KEY_TOO_WEAK or some such hack [16:08:59] jhutz: Should the client include the root CA cert be in the chain? [16:09:02] I haven't payed attention to that part of the I-D [16:09:15] russ: if you include the root CA cert in the chain, _I_ will send it back :-) [16:09:21] So I don't think that there's a real way to negotiate [16:09:23] its sends back and error code and with use this group in a PA [16:09:56] s/its/the kdc/ [16:10:13] If there was a way to negotiate, I think we would have used it [16:10:19] --- amelnikov has left: Replaced by new connection [16:10:19] --- amelnikov has joined [16:10:19] --- amelnikov has left [16:10:20] doc: you mean that we don't know if KEY_TO_WEAK means cert too week or DH group too weak? [16:10:27] But if you're sure, then I won't argue [16:10:29] do we need a new error? [16:10:32] --- amelnikov has joined [16:10:33] we're not sure [16:10:35] ! [16:10:50] nico: Are you covering sam? [16:10:57] ok, hartmans talking about pre-auth [16:10:58] yes [16:11:00] its not a new error, its covered by the spec [16:11:09] KEY_TOO_WEAK menas you have to strengthen the value, but maybe it's really too strong and you want to negotiate downward [16:11:14] security analysis of ashing pre-auths together is hard [16:11:29] hartmans [16:11:51] hartmans: there will be a pre-auth combination pre-auth type [16:11:57] or something [16:11:58] Can't we say MUST support group 2 and SHOULD support a and all the ones i nthe later RFC? [16:12:09] hartmans: where to keep state is an issue [16:12:12] doc: That was a recommendation. [16:12:13] I wish that I could type [16:12:28] OK; I would agree to that recommendation [16:12:28] doc: heh [16:12:45] sam: think I have a solution that will send to list [16:13:10] send to list when? [16:13:39] sam: negotiation, ordering [16:14:22] I don't like the idea of negotiation if it's going to require more than a single exchange [16:14:30] sam: could negotiate ordered pre-auth method from set of such [16:14:50] doc: I'lll say more when sam sits down [16:14:51] :) [16:14:58] sam: will need help [16:15:15] reviewing, drawing ascii art [16:15:19] sam's done [16:15:25] IN CableLabs right now group 2 is a MUST to support, group 1 is a MAY [16:15:32] brian: I can help with ASCII art. [16:16:06] I think I'm up [16:16:13] no, I'm not [16:16:15] Leif is [16:16:22] :) [16:16:29] kenh: you scrib ethis time [16:16:40] I found it harder to scribe Sam than I'd thought [16:16:57] nico: will do. [16:17:04] doc: pre-auth combination will require multiple round-trips [16:17:09] Leif: krb-information-model. [16:17:11] Negotiation will require no new round trips [16:17:19] No current comments (AFAIK) [16:17:19] the negotiation will not require more than one [16:17:20] I don't like the idea of negotiation [16:17:25] Orthogonal to change-password [16:17:34] part of any management protocol. [16:17:39] oh, ok, I'll let Sam speak for himself [16:17:52] I can send the signing propoasl out given 10 minutes or so. [16:17:53] hartmans: I can read preauth and review [16:17:53] Seems to have exhausted WG momtentum; seems pretty complete. [16:18:04] We need WG review at this point. [16:18:25] (as a FYI: key management is not intended to be done with this draft). [16:18:26] Leif's slides: info-model-ietf60.sxi [16:18:50] sam: Presented this to a vendor, they were interested, have some feedback to send your way. [16:18:58] negotiation is needed as long as we think we need to combine preauth mechs (ie there isn't a secure preauth mech that can stand on its own) [16:19:00] sam: We will try to get that feedback to you. [16:19:18] Or we think that we want to support combining mechs. [16:19:26] leif: Comments from two IETFs ago were folded into latest draft. [16:19:37] nico: I will review it, and let you know if I have any issues. [16:19:53] sam: I would like it if it was a WG document. [16:20:21] jhutz: Don't have text of charter right now, but I think it fits within scope. [16:20:54] hartmans: how can we not need it unless we do something like SRP for password auth [16:21:01] jhutz: My opinion is that I would like it to be a WG item: [16:21:17] Consensus is for having it WG item (no objections) [16:21:25] Russ: Get PKINIT done first. [16:21:48] leif: Will accept any comments on it. [16:22:03] Where can I find Leif's slides? [16:22:26] doc: We're working on it. [16:22:36] Oh, OK. Thanks. [16:22:54] It's tough here, trying to participate in a real meeting at the same time [16:23:22] Nico Williams: set-passwd-v2 [16:23:36] Removed some authors, added acknowledgements [16:23:56] http://people.su.se/~leifj/info-model-ietf60.pdf [16:24:02] Removed UDP as transport, redundant framing, ASCII art. [16:24:39] Cleaned up major version negotiation text. [16:24:52] (Removing UDP helps in this regard) [16:25:07] I18N: To be discussed here. [16:25:36] Added dry-run (password test) capability. [16:26:15] Added op to get current s2k params without password change. [16:26:23] (To sync salts after princ/realm renames) [16:26:45] Added optional password quality codes as hints for smart clients (by req from Larry) [16:27:09] Added delayed commitment to change-pw and set-pw operations (requested by Larry) [16:28:36] Larry: I'd like to be able to negoiate error code support so we could add error codes without IETF intervention. [16:28:44] nico: We'll take this to the list. [16:30:07] hey, had to step away for a minute. Where are we on PKINIT? [16:30:26] Removed field indicating version of Kerberos V5 support (convinced by Sam)> [16:30:33] outstanding issues to the list [16:30:35] Eric: Can you scroll back in your jabber client? [16:30:36] (pkinit) [16:30:37] eric: we ran out of time [16:31:07] Nico: The isupport issues may still be controversial (sam said to take offline) [16:31:21] Nico: I18N, Baby One More Time. [16:31:36] Not just just-send-8, but also just-use-8. [16:33:15] just-use-8: When a client and a server are trying to auth, they have better had the same encoding. [16:33:21] yeah, I have scrolled back, and I didn't see a whole lot of resolution. So what does "ran out of time" mean? I thought PKINIT was the highest priority. [16:33:50] re s2k params: Was it out of the question to allow clients to suggest string2key parameters? [16:34:24] i18n is also high on the list - anyways most of the questions need confirmation on the list anyway [16:34:24] We had some issues that consensus was declared in the WG, but we have to ask the WG on the mailing list (since not all the players are here) [16:35:28] Nico: Dual-mode (pre-ext/ext) require aliasing of non-ASCII princ/realm names, salts, passwords if we want them to be used on pre-ext just-8 clients. [16:36:17] Nico: salts & passwords should be sent a display strings to help out pre-ext clients. [16:37:03] SASLprep explicitly prohibits ASCII control characters in their passwords, but current KDCs support it. Probably is a non-issue. [16:37:53] Consensus is for adding encoding hints to protocol (no objections) [16:39:40] Out of the people who read extensions, no one has objections to doc structure. [16:39:49] Doug Engert: Kerberos self-limitations. [16:40:05] Doug: Kerberos too succesfull: [16:40:23] Trust in user's workstation is low (bigger you get, the smaller the trust) [16:40:36] With single sign-on, total reliance on user's workstation. [16:40:49] Delegated ticket is as good as original. [16:41:47] No black-listing of tickets by KDC, especially with cross-realm. [16:42:06] I think host security is the real long-term solution to this problem [16:42:15] --- wyllys has left: Disconnected [16:42:32] I'd like an authorization data item or binding a ticket to a host principal [16:42:33] or stick Kerberos in the TCB [16:42:43] I don't disagree, but that's a really hard problem. We could provide some better knobs. [16:42:51] nico: fine, but that requires TCB-level integration [16:42:57] in the ticket: the princ name [16:43:08] kenh: But all the OS vendors are working on it. [16:43:29] in the authenticator: another AP-REQ for the bound princ sing the checksum field to bind that AP-REQ to the outer one [16:43:40] Doug: Conclusions, is that we need more input from the "real world". [16:44:10] hartmans: they are? How so? [16:44:12] --- raeburn has left: Disconnected [16:44:34] Linux is working on selinux; Nico tells me wonderful things about Solaris 10 every time we talk [16:44:39] tlyu: These are really qualitfy-of-implementations issues, not so much protocol issues. [16:44:57] heh [16:45:05] Ah, I thought you were talking about authorization knobs, not host security. [16:45:07] Windows actually does a lot of this already although default policy is permissive [16:45:42] ken: I'm addressing Doug's point about binding to addresses being useless [16:45:42] Larry Zhu: KDC Referrals [16:45:50] I don't buy this is Kerberos specific except in so far as Kerberos actually provides a usable experience so you can get it working far enough to get compromised [16:46:15] nico: Okay, but I think he meant in practice, not in theory. In practice, _what we have currently_, they are, IMHO. [16:46:26] But we could certainly have something better. [16:46:33] Larry: Updates [16:46:54] Larry: PA-SERVER-REFERRAL-DATA contains the realm name for the next TGS Request. [16:47:01] kenh: Possibly I'm not convinced we could have something better that provides a good user experience but I'm happy to try [16:47:09] Solution to the GNU FTP problems. [16:47:32] (e.g., Using an alias GNUFTP to request a ticket for ftp.gnu.org, outside of admin boundary) [16:48:06] Referral data could refer you to the "correct" name. [16:48:36] Everyone is breaking out the beers here, so er... I have to leave now... [16:48:41] sam: Oh, I don't know how to create anything better, I'm just saying it would be nice if therre was such a thing :-) [16:48:49] --- Eric Rosenfeld has left [16:48:50] see ya, doc [16:48:51] Larry: Open Issues [16:48:56] --- N7DR has left [16:49:04] Larry: Ticket & referral info mix & match attack [16:49:07] Ah, but I do know how to make progress on host security;) [16:49:18] Several Solutions possible [16:50:00] sam: The problem is that if your user base includes mostly random scientists connecting from poorly-administrated Linux boxes, your host security problem is VERY hard. [16:50:13] Larry: Several solutions possible (see slides) [16:50:42] Larry: Next steps - call for consensus on the draft going to last call. [16:51:06] jhutz: Last call is something Doug and I do when we feel the document is ready ... and we base that on your sense of the document's readiness. [16:51:08] --- nov has joined [16:51:09] --- lha has left: Logged out [16:51:18] --- lha has joined [16:51:39] are we done? looks like it [16:51:42] sam: I think you're not ready; you probably need a few more reviewers. [16:52:09] jhutz: Please describe your proposals on the mailing list, so we can get more discussions. [16:52:14] --- hartmans has left [16:52:24] --- nico-sun has left [16:52:46] --- tlyu has left [16:52:54] And the meeting is closed. [16:53:01] --- nov has left [16:53:07] --- kenh has left [16:53:21] --- pbh has left [16:55:36] --- jas has left [16:55:44] --- DougEngert has left [16:55:47] --- lha has left [16:59:42] --- amelnikov has left [17:07:47] --- jhutz has left: Disconnected [17:10:21] --- masahiro has left: Disconnected [17:13:02] --- jaltman has left: Replaced by new connection [17:13:25] --- jaltman has joined [17:15:35] --- warlord has left [17:17:57] --- masahiro has joined [17:18:01] --- masahiro has left [17:18:17] --- Kurt has left: Disconnected [17:22:53] --- leifj has left [17:44:18] --- jhutz has joined [17:47:50] --- wyllys has joined [17:48:02] --- wyllys has left [17:48:56] --- jhutz has left [18:20:55] --- raeburn has joined [18:25:21] --- jaltman has left: Replaced by new connection [19:05:45] --- raeburn has left: Disconnected