krb-wg@conference.ietf.jabber.com - 2002/11/19

[10:52] %% mrose has arrived.
[10:52] %% mrose has left.
[10:52] %% mrose has arrived.
[11:02] %% rjs3 has arrived.
[11:08] %% leg has arrived.
[11:10] <leg> chair finally finds a note taker (me)
[11:10] %% jhutz has arrived.
[11:10] %% hartmans has arrived.
[11:10] <jhutz> sucker
[11:11] <leg> agenda bashing; move IAKERB next to EAP?
[11:12] <leg> current agenda is at http://www.ietf.org/ietf/02nov/krb-wg.txt
[11:12] <leg> cliff neuman to discuss clarifications
[11:13] %% warlord has arrived.
[11:14] <jhutz> test
[11:14] <warlord> pass
[11:15] <leg> chair and cliff are cooperating on how to increase the font in mozilla
[11:15] <leg> presentation starting; today is the end of the WG last call on clarifications
[11:17] <jhutz> assar clearly read the document through -- most of his comments were language and formatting nits, rather than technical issues
[11:17] %% aamelnikov has arrived.
[11:17] <jhutz> http://www.kerberos.us/
[11:18] <leg> http://www.kerberos.isi.edu/ has the latest on clarifications, including "pending edits" and "issues for extensions"
[11:19] <leg> rather, http://www.isi.edu/people/bcn/krb-revisions/
[11:20] <leg> sam hartman brings up authorization data SHOULD versus MUSTs
[11:22] <leg> appears to be consensus that "encapsulating authorization data" MUST be rejected if not understood
[11:25] <leg> probably will be another WG last call which will allow any new issues as well as making sure that issues during this last call have been dealt with
[11:26] <leg> end of clarification discussion
[11:26] <leg> next item: ken raeburn and encryption & checksum specification
[11:27] <leg> appears that clarifications, encryption, and AES docs will all have to move simulatenously
[11:27] <leg> ken talking about latest changes to encryption docs
[11:28] <hartmans> Sometimes I wonder whether the simplified profile actually is.
[11:28] <leg> ken talking about AES document changes: dropped twofish, dropped 192-bit AES.
[11:29] <leg> going to be another version of the crypto draft to fix DES problems
[11:29] <jhutz> it eliminates parts of the design process where people are most likely to screw up. Still, I have more confidence when the people designing new enctypes know what they're doing
[11:30] <jhutz> Why do I think that IAKERB is going to be more controversial than its 5 minutes on the agenda?
[11:30] <hartmans> Who is speaking on iakerb?
[11:31] <jhutz> glen zorn
[11:31] <hartmans> Ken talks about exposing dr from simplified profile into section 2
[11:31] <warlord> Oh, I get to speak beside glen?
[11:32] <jhutz> yeah, given the agenda changes, I think you do
[11:32] <leg> issue: generating random data to feed into algorithms for combining keys (?)
[11:32] <leg> solution: add a function to the crypto profile?
[11:32] <hartmans> That's the motivation but really you want a what ammounts to a PRF in the encryption operations
[11:33] <leg> no discussion on ken's presentation
[11:33] <leg> next up: matt hur to discuss PKINIT
[11:35] <leg> very few changes in the past few revisions. he's summarizing recent changes.
[11:36] <leg> goal is to last call this document shortly after clarifications
[11:37] <leg> tom yu brings up RFC 2253 transformation from cert to principal isn't unique
[11:38] <hartmans> Who is speaking?
[11:38] <leg> kurt zelinga: 2253 talks about reversible mappings in the security considerations. (use section 2.3 form?)
[11:39] <leg> tom yu: problem with sticking ASN.1 into the ticket because that requires application changes
[11:41] <leg> tom yu/matt hur: PKINIT defines a mapping to a string from certificate. we need to find a good one.
[11:41] <hartmans> mic: Just stick with extension to map cert to kerberos name
[11:42] <leg> that was leif
[11:42] <leg> tom yu: what was the goal of PKINIT?
[11:43] <leg> current draft leaves the mapping mostly up to site policy. is this ok?
[11:43] <hartmans> tlyu: Points out all this is left up to site ploicy; is that good?
[11:43] <leg> leg/rlbob: yes
[11:44] <leg> matt hur: CA is treated as a seperate realm
[11:44] <leg> ty: need X.500 CA to Kerberos realm to be unique and probably reversible. which might mean we have to give up on it being human readable.
[11:45] <hartmans> Why does it need to be reversable? I understand unique.
[11:45] <warlord> To add entries to acls?
[11:46] <hartmans> Add the mapped version
[11:46] <leg> jeff: a lot of this is site specific. the document needs to provide recommendations/examples. one example could be using X.509v3 extensions to help with the mapping.
[11:46] <leg> mh: there is no MUST implement policy?
[11:46] <leg> jeff: no. (what's jeff's last name?)
[11:47] <hartmans> Jeff Altman
[11:47] <jhutz> Oh, jaltman is speaking now
[11:47] <leg> mh: do you agree there has to be another way of using the name?
[11:48] <leg> ja: what name?
[11:48] <leg> mh: we thought we should have a canonical mapping.
[11:49] <hartmans> jaltman: We're Kerberos; we acl based on Kerberos names not cert names
[11:49] <leg> ja: there are lots of ways. some use fingerprints and LDAP lookups, etc.
[11:49] <hartmans> so not ready for last call
[11:50] <leg> ja: where i get confused is where the document talks about presenting a certificate directly to a service and a service returns a service ticket.
[11:50] <jhutz> wait. isn't this direct-to-service thing PKTAPP ?
[11:50] <leg> chair: in direct-to-service, the service can use whatever name it wants; it's doing the authorization
[11:51] %% rlbob has arrived.
[11:51] <hartmans> I thought this was ktap too and was not part of the raw pkinit draft.
[11:51] <leg> kr: but you should want the cert -> principal mapping to be the same regardless if it's a KDC or an application server
[11:52] <leg> ty: you can't allow completely arbitrary mappings because vendors will do it differently in apps and KDCs and then a site won't be happy interoperating
[11:52] <leg> mh: let's try to generate more discussion on the list on this.
[11:53] <leg> mh: other minor corrections to be made. uncontroversial.
[11:53] <leg> chair: next item was iakerb, but we're moving to kerberos change password
[11:54] <jhutz> (iakerb was moved to later in the agenda, adjacent to eap)
[11:54] <leg> sam hartman: issues on pwchange
[11:55] <leg> issue #1: pwchange doc implicitly changes kerberos protocol: says must not set addrs on krb_priv. contradicts what we're doing for clarifications
[11:55] <leg> sh: can use directional address type
[11:56] <leg> issue #2: i18n. currently specifies UTF-8.
[11:56] <leg> sh: we want something that works now, and works after we fix kerberos to be i18n.
[11:57] <leg> one problem is non-unicode characters. (no big deal; just prohibit them.)
[11:58] <leg> second problem: we want a stringprep and we want that version to end up in the kdc
[11:58] <leg> if we normalize on the client, transitioning is harder.
[11:59] <leg> further, normalization is defined in extensions. do we want to block pwchange on extensions?
[11:59] <leg> suggested solution: 1) no non-unicode characters. 2) send the unnormalized UTF-8 to the server.
[12:01] <leg> maybe for now we specify unicode/utf-8, and say if you send anything but US-ASCII you might not be interoperable
[12:01] <leg> issue #3: dealing with site server wants to enforce that you have a random key. does anyone else care?
[12:03] <leg> chair: the room things the i18n issues are important
[12:04] <jhutz> what's the name of the draft again?
[12:05] <leg> microphone: preventing the server from being a free source of entropy is bad. if fixing issue #3 stops that it would be good.
[12:06] <leg> sh: my fix doesn't fix that problem
[12:07] <leg> chair: sees a consensus that the pwchange should be withdrawn from IESG so we can fix and resubmit
[12:08] <leg> leif: a fix to pwchange may change the ldap-schema problem
[12:08] <leg> chair: now 2 o'clock; 15 minute break.
[12:11] %% aamelnikov has left.
[12:12] %% aamelnikov has arrived.
[12:15] %% mrose has left.
[12:16] %% mrose has arrived.
[12:23] %% leg has left.
[12:23] %% leg has arrived.
[12:23] <leg> aha
[12:23] <leg> we're back
[12:24] <leg> next up is cliff with extensions
[12:26] <leg> revisions begat clarifications and extensions. blah blah blah
[12:29] <leg> extension goals: extensibility, i18n, ticket extensions, canonicalization
[12:32] <warlord> too many Jeff's in here
[12:32] <jhutz> there are too many jeff's in the room
[12:32] <leg> ja: i18n extensions is about normalization.
[12:33] %% jis has arrived.
[12:34] <leg> sh: we were folding in client canonicalization into extensions. i think the objections had disappeared.
[12:35] <leg> update MUSTs: but this is mostly done in clarifications
[12:35] %% jis has left.
[12:36] <leg> direction address types: partly addressed in clarifications but something might have to be done in extensions
[12:36] %% jhutz has left.
[12:37] %% jhutz has arrived.
[12:37] <leg> ty: edata stuff to fix: authenticated cleartext, typed data inside of edata.
[12:40] <leg> sh: consensus in febuary that typed data wasn't the general solution. still outstanding questions
[12:43] <leg> sh: problems with name space constraints are pointed out in the clarification documents. it would be nice if they were addressed in extensions.
[12:44] <leg> chair: are there relationships between pkcross and name space constraints?
[12:44] <hartmans> If you are doing cross-realm-traversal and get a referal to another KDC you can poison your cache
[12:44] <leg> cliff: some amount of backwards compatibility is also a goal for extensions
[12:45] <hartmans> I think that's a ibt of an understatement.
[12:45] <jhutz> Yeah; the "name space constraints" item on the TODO list has to do with the cross-realm cache poisoning issue.
[12:45] <leg> cliff: [lots of neato stuff enabled by extensions]
[12:45] <jhutz> IIRC, we had concensus in February that backward compatibility with RFC1510 was a requirement for extensions
[12:45] <hartmans> We want full backward compatibility. The hard part is maintaining that and going forward
[12:46] <leg> mh: is this an extension to v5 or is this v6?
[12:46] <leg> jhutz: can we avoid this discussion?
[12:46] <leg> sh: when does this ever matter?
[12:48] <jhutz> Looks like we're going to have to do this again. <sigh>
[12:48] <leg> mh: if we just rev to v6 we can try to simplify this. if we don't rev the version we get lots of hard to tell apart v5 implementations.
[12:48] <leg> ty: why do you care about what v5 means?
[12:49] <leg> mh: it's hard to claim to compliance if the version never changes
[12:49] <hartmans> tlyu: There is this thing called an RFC number; it does not change
[12:50] <leg> chair: moving on
[12:50] <leg> chair: IAKERB and K5 EAP. similiar but not the same...
[12:51] <hartmans> Both solve initial creds and then Kerberos auth for things like dialup
[12:51] <leg> one is purple one is blue
[12:52] <jhutz> One is black-and-blue; the other is merely blue
[12:52] <warlord> No, it's purple v. GREEN!
[12:52] <leg> glen zorn: IAKERB is at -09 and i'm not familiar with Martin Rex's objections.
[12:52] <jhutz> Aw. So sorry if you've deployed something based on an internet-draft that was not the result of WG concensus
[12:53] <leg> gz: IAKERB was deployed by Symbol?
[12:53] <leg> crowd: Symbol does K5 in a proprietary way. doesn't use EAP or IAKERB.
[12:53] <warlord> No, it is not.
[12:53] <warlord> er, what leg said the second time.
[12:54] <leg> huh?
[12:54] <jhutz> actually, what the crowd said
[12:54] <warlord> right
[12:55] <leg> gz: what are martin's objections?
[12:55] <hartmans> It was the result of WG consensus not IETF consensus though
[12:55] <leg> chair: one of them was that it was unimplementable.
[12:55] <leg> gz: there is an implementation but it isn't shipped.
[12:56] <leg> jhutz: i will channel martin. "using spnego in this protocol has no value"
[12:56] %% jiri has arrived.
[12:56] <leg> jhutz: "iakerb is underspecified for a GSS mechanism" "no two implementations will interoperate"
[12:57] %% mrose has left.
[12:57] <leg> gz: jonathan trossel thought that he had addressed martin's comments.
[12:57] <leg> chair: jis was suppose to read the document and comment.
[12:57] <leg> sh: does IAKERB work with preauth?
[12:58] <leg> ja: it can't use preauth.
[13:00] <leg> jhutz: by not allowing for multiple roundtrips it doesn't allow for extensions that might be more flavorful with multiple roundtrips
[13:00] <leg> gz: the argument it's not futureproof is very hard to deal with
[13:00] %% jiri has left.
[13:00] <jhutz> heh. I can sometimes get away with no mic. raeburn cannot
[13:01] <hartmans> Does MS implement iakerb?
[13:01] <leg> ken raeburn: if this is using password authentication we really want multiple roundtrips
[13:02] <leg> (as myself) how can preauth be weaker? i'm confused.
[13:02] <hartmans> gz: I argued against preauth in wireless situations etc
[13:03] <jhutz> why is gz representing this draft?
[13:04] <leg> chair: running low on time.
[13:04] <leg> ja: why didn't jonathan respond to martin?
[13:04] <hartmans> jis has good timing in disappearing when he would be on the spot
[13:04] <leg> ja: we need an editor who will address these issues.
[13:05] <leg> chair: what should we do with the document?
[13:05] <leg> gz: i don't like experimental.
[13:06] <leg> [i'm having huge lag here...]
[13:08] <jhutz> I haven't seen any lag so far...
[13:08] <jhutz> "My name is Derek Atkins, and I work for IHTFP consulting."
[13:09] <jhutz> I don't know what leg's problem is.
[13:09] <jhutz> hartmans asked whether the WG felt iakerb should be dropped as a WG work item.
[13:09] <jhutz> chari asked for a show of hands; determined there was _not_ concensus to drop the item.
[13:10] <jhutz> time is short; further discussion deferred to the list
[13:10] <jhutz> warlord (Derek Atkins) is now talking about his krb5 EAP method
[13:17] <jhutz> warlord: draft is not published because it is only half-written
[13:17] <jhutz> warlord: would krb-wg be willing to take this as a work item? I am also asking eap
[13:17] <jhutz> hartmans: new mechanisms are specifically out-of-scope for eap
[13:17] <jhutz> chiar: time running short. let's move on. we'll give kenh 5 minutes combined for his items
[13:18] <jhutz> kenh discussing passwordless initial authentication (draft-ietf-krb-wg-hw-auth-02.txt)
[13:18] <jhutz> kenh discussing single-use auth mechanisms (draft-ietf-krb-wg-kerberos-sam-01.txt)
[13:19] <jhutz> I wonder if anyone else is still seeing this...
[13:19] %% jhutz has left.
[13:20] %% jhutz has arrived.
[13:20] <jhutz> Donna Skibbie will talk about the LDAP schema
[13:45] %% jhutz has left.
[13:48] %% rjs3 has left.
[13:53] %% warlord has left.
[15:57] %% jhutz has arrived.
[15:57] %% hartmans has left.
[15:57] %% leg has left.
[15:57] %% aamelnikov has left.
[16:01] %% jhutz has left.