Love wrote:

It was unclear that this was about reordering the structure of the document so I just read it doing review of the ASN1 and not the structure of the document. The asn1 is really painful. Its just way too much new asn1 feature used. I found it unclear from the boulder minuts that this was the way it going to take. I'm not pleased and talked to Tom about it at last IETF. the proposeal to have to version (where one is expanded) I find really bad, just do one of them. Love

I find the updated ASN.1 conceptually much easier to
understand.  If I was forced to choose one, it would
be the one with the new ASN.1 features.

- Jeff

[18:54] jaltman has entered the room.
[18:54] chatroom for krb-wg working group
[18:54] larry has entered the room.
[18:54] tlyu has entered the room.
[18:54] Eric Rosenfeld has entered the room.
[18:54] kenh has entered the room.
[18:54] jas has entered the room.
[18:54] warlord has entered the room.
[18:54] BCNeuman has entered the room.
[18:54] Doc Evans has entered the room.
[18:54] DougEngert has entered the room.
[09:12]<DougEngert> Good Morning Ken
[12:09]<larry> huh, I am here too1
[12:12]<Doc Evans> Hi, Larry
[12:24]<larry> hi, good morning Doug
[12:26]<Doc Evans> Doug's not here
[12:26]<Doc Evans> Just you and me
[12:27]<Doc Evans> Ken is loggesd in, but I assume that he's sleeping
[13:01]<Doc Evans> Sorry about the multiple joins... trying to configure Psi so that it does the right thing, and it seems to need to be stopped and re-started for some of the changes to work properly
[15:21]<DougEngert> Checking of this works from the office.
[17:47]<raeburn> Hello.  Good morning/afternoon/evening, as appropriate...
[17:48]<larry> is there anything happening here?
[17:48]<raeburn> (Is anyone who's on right now actually in Seoul?  It's something like 8AM there now, isn't it?)
[17:48]<Doc Evans> good afternoon
[17:49]<Doc Evans> I don't think that any Seoul people are here
[17:51]<Doc Evans> Time for tea here
[18:23]<BCNeuman> Hello all, if my timezones are correct, I think the meeting starts in half an  hour?
[18:26]<DougEngert> I hope so
[18:30]<Kerberos WG> Hello.
[18:32]<DougEngert> So who is/was "Kerberos WG"?
[18:32]<Eric Rosenfeld> um, that was me. I put in incorrect nickname.
[18:33]<DougEngert> OK, thought it might be someone at the meeting.
[18:38]<kenh> howdy all.
[18:39]<DougEngert> Ken, Are you at the meeting?
[18:39]<kenh> affirmative.
[18:39]<DougEngert> Well tel us how things are going?
[18:40]<kenh> okay ... right now it's still 15 minutes before it starts 
[18:54] The topic has been set to: krb-wg working group
[18:54]<warlord> who is the jabber scribe here?
[18:54]<Doc Evans> The best typist in the room, I hope
[18:54]<jaltman> hello all
[18:56]<jaltman> is there multicast for this session?
[18:56]<warlord> unlikely based on the room
[18:57]<jaltman> mine has a nice view 
[18:57] hartmans has entered the room.
[18:57]<kenh> I offered to be the jabber scribe, but I'm not sure if I'll be the best scribe.  Obviously, I can't produce regular notes at the same time.
[18:57]<hartmans> Cliff, do you believe there are any outstanding issues on clarifications?
[18:58]<hartmans> I'm digging up your mail
[18:58] raeburn has entered the room.
[18:58] jhutz has entered the room.
[18:59]<jhutz> where's Brian?
[18:59]<BCNeuman> I do not believe that there are.  There was on issue where that had been discussion, but no consensus that I did not include an update for.  Sam later mentioned that he said he was OK with the change, but I don't think it was a significant change anyway, so I am hoping this goes through as it is.
[18:59]<jhutz> There is not multicast.  We asked, but we did not get it
[19:00]<jaltman> thanks for asking
[19:00]<jhutz> We'll wait a couple of minutes longer, since it's not actually 9 yet
[19:00]<jhutz> Maybe we can hold the next interim meeting on jabber...
[19:01]<warlord> we'd need a jabber-based white-board app.  does one exist?
[19:01]<DougEngert> Looks like most of the WG is on line.
[19:01] lha has entered the room.
[19:01]<Doc Evans> There's an experimental JEP on whiteboarding
[19:01]<Doc Evans> but nothing solid
[19:02]<BCNeuman> The one issue I was referrig to was the new text for the ctime, cusec, cream, cname, realm and sname fields.
[19:02]<hartmans> Nod
[19:03]<BCNeuman> Did Brian confirm he would be on.  I'm at home now (went home to install gabber and take the conference participation from here).
[19:04]<BCNeuman> I'm calling Brian now, but not getting an answer.
[19:05]<kenh> Okay, I guess I'm scribe.
[19:05]<kenh> Jeff Hutzelman is opening the meeting.
[19:05]<DougEngert> Who is at the meeting that is not on Jabber?
[19:05]<kenh> love and wyllys ingersoll.
[19:06]<kenh> jhutz: Welcome to krb-wg.  Doug Engert could not be here today.
[19:06]<BCNeuman> I just spoke to Brian.  He plans to be on, but has to get his jabber client started.
[19:06]<kenh> Call for volunteers: scribe, jabber, and mic interface.
[19:07]<kenh> me for jabber scribe, love for mic interface.
[19:07]<lha> I'm supposed to be a mic interface for you all jabber people
[19:07]<kenh> no scribe currently, jhutz will synthesize them.
[19:08]<kenh> agenda bashing: no comments.
[19:08]<kenh> first item on agenda: crypto framework.
[19:09]<hartmans> Ken issues resolved with crypto?
[19:09]<kenh> raeburn believes all issues are resolved.
[19:09]<kenh> AD (Russ) checked the current status, said new draft cleared Allison's discuss, only thing left is Thomas Narden's.
[19:10]<kenh> next up: clarifications.  Author believes all issues are resolved.
[19:10]<kenh> Russ: three discussion items, will require more work.
[19:11]<BCNeuman> I have not seen any subseqent comments from Russ.  What are the issues?
[19:11]<kenh> Next: GSSAPI-CFX.  Issues were brought up, document author submitted a new version before cut-off.
[19:11]<raeburn> Ah, good.  I kept forgetting to let Russ & Thomas know the new version was in. 
[19:11]<raeburn> (of crypto.  sorry, i'm a little slow)
[19:12] alexeymelnikov has entered the room.
[19:12]<kenh> It is believes that all issues are resolved with GSSAPI-CFX.
[19:12] rlbob has entered the room.
[19:12]<kenh> hartmans: I believe we're in pretty good shape regarding kerberos extensions.
[19:12]<kenh> hartmans: Authors have gotten together, shared CVS repository to resolve bottleneck issues.
[19:13]<kenh> hartmans: IESG wanted them to use a different issue tracker than the one that they're using, not a big deal.
[19:13]<kenh> hartmans: Big issue is text - we don't have any.
[19:14]<kenh> hartmans: Meanwhile, Tom Yu has never liked the structure of extensions, and has a draft for an alternative proposal.
[19:14]<kenh> jhutz: Questions/comments about extensions?
[19:14]<jaltman> Tom: what is your proposal?
[19:15]<kenh> hartmans: draft-yu-krb-wg-kerberos-extensions-00
[19:15]<jaltman> thanks
[19:15]<kenh> hartmans; Alternate document structure for extensions - ideally draft describes same wire protocol.
[19:15]<kenh> hartmans: Clarifications is both too verbose and too unclear.
[19:16]<kenh> hartmans; Content is duplicated between sections 3 and 5.
[19:16]<kenh> hartmans: E.g., you have to refer back and forth between sections 3 and 5 to understand the complete message semantics.
[19:17]<kenh> hartmans: motivations are to fix these issues.
[19:17]<jaltman> http://www.ietf.org/internet-drafts/draft-yu-krb-wg-kerberos-extensions-00.txt
[19:17]<kenh> hartmans: Goals - give document hierarchical reorg, put sematics in one place, integrate semantics and message definitions, remove implementation-specific details (e.g, kdb description in rfc1510)
[19:18]<kenh> hartmans: Accomplishing these goals: Move all overview material to beginning before message descriptions.
[19:19]<kenh> hartmans: Treat TGS and AS request as specializations of more general KDC request.  Tom believes it will be easier to to understand if requests are described more generally and describes differences between TGS_REQ and AS_REQ.
[19:20]<kenh> hartmans: Describe in terms of ASN.1 types.
[19:20]<kenh> hartmans; New document layout - Overview, basic concepts, individual sections for three protocols of Kerberos (each protocol described seperately).
[19:21]<kenh> hartmans; Description of overivew - Trusted third party, identify parties in Kerberos exchanges.
[19:21]<kenh> hartmans: Basic Kerberos concepts - ASN.1 usage, principals, encrypted data (ref to crypto framework), composition of tickets.
[19:22] BrianTung has entered the room.
[19:22] BrianTung has left the room.
[19:22]<kenh> hartmans: Three protocols - Credential acqusition (AS_REQ/TGS_REQ), Application Authentication (AP_REQ), Session key usage by applications.
[19:23] BrianTung has entered the room.
[19:23]<kenh> hartmans: Credential acquisition - describe common elements of KDC request handling, better discussion of keys in this request, clear up timestamp handling.
[19:23]<BrianTung> OK, I'm on.
[19:25]<kenh> hartmans: Missing from document - discussion of naming issues, discussion of transport, instances of the typed holes (ETYPE_INFO2), empty sessions.  All things clearly needed to be added, only reason they are missing is due to lack of time.
[19:27]<kenh> hartmans: Questions for WG - Is this structure easier to understand than clarifications, and how should we choose which structure to adpot?
[19:27]<kenh> hartmans: Note that ASN.1 is very different in extensions - one person has objected to this already.
[19:27]<kenh> russ: Summary of ASN.1 issues, please?
[19:28]<kenh> hartmans: In summary, we used nearly every feature we could get our hands on (like information object elements).
[19:29]<kenh> hartmans: note that an appendix will include the ASN.1 structure with the information elements templated out.
[19:29]<kenh> jhutz: Issue of what protocol we are or are not going to have is not relevant to this particular discussion.
[19:30]<jhutz> Slides for the presentation just finished are at http://www.cs.cmu.edu/~jhutz/extensions.pdf
[19:30]<kenh> jhutz: Three questions for WG
[19:30]<kenh> Who read tom's proposal?
[19:31]<hartmans> (We want answers from here)
[19:31]<kenh> (jhutz is asking jabber participants)
[19:31]<BCNeuman> I have read it.
[19:31] rickravaya has entered the room.
[19:31]<raeburn> not in detail yet
[19:31]<DougEngert> Looked it over.
[19:31]<jaltman> I have just scanned it.  I think the layout looks much easier to approach when compared to our previous texts.
[19:32]<Doc Evans> I scanned it and like the layout
[19:32]<Doc Evans> Someone not well-versed in this stuff might stand a chance of implementing it correctly quite quickly
[19:32]<kenh> jhutz: Do people think this is easier to understand than clarifications? (Already seen the answers from some jabber participants, more are welcome)
[19:32]<BCNeuman> Layout is cleaner, in part because I think we dispense with a lot that had to be in clarifications for completness and paralleling the original 1510.
[19:33]<raeburn> What I've looked at so far, yes, but that's not a lot.
[19:33]<kenh> jhutz: Unclear how to choose which structure we should adopt.  What criteria do we think are important?
[19:33]<kenh> Tom, do you want to comment on this question?
[19:34]<Doc Evans> 1. Precision; 2. clarity for a developer who has never implemented this before
[19:34]<tlyu> i think clarity and good organization are important
[19:35]<tlyu> while i agree that we should not be writing a tutorial, we should still approach things in an orderly top-down fashion.
[19:35]<jaltman> I think there is a benefit to a re-org in that it will cause us to think about re-writing sections which we would not otherwise touch if we were simply extending upon Clarifications.
[19:35]<jaltman> Tom has already taken a big first couple of steps in this direction
[19:36]<jas> both documents need much more details if you want to implement it from the document only.  the layout, while nice, can't compensate for lack of details.
[19:36]<kenh> jhutz: Looks like there is more support than not; will take this to the mailing list, will try to get it resolved in the first few days after we get back.
[19:36]<jhutz> [who is jas?]
[19:37]<jas> [simon josefsson]
[19:37]<warlord> [hi simon]
[19:37]<kenh> love: I think it is worth considering the cost it will take to rewriting the spec versus just starting from clarifications.
[19:37]<kenh> jhutz: Next item on agenda - PKINIT
[19:38]<kenh> jhutz: Note to jabber scribe - be extra careful.
[19:38]<hartmans> ==warlord  Good to have other implementers here; hi Simon
[19:38]<lha> [love entries are tunning people in jabber]
[19:38]<BrianTung> I don't think it will be a problem, but I have to leave for about 20 minutes at 5:30 PST (that is, in about 55 minutes).
[19:38]<kenh> jhutz: draft-ietf-cat-kerberos-pk-init-18.txt
[19:39]<kenh> jhutz: Everything in here should be up-to-date, taking a bit longer than we hoped, but should be no more unforseen issues.
[19:39]<BrianTung> pk-init-18.txt includes mostly changes that were agreed on in principle in November.
[19:39]<BrianTung> I've done some of the things improperly (like the IMPORTS), but I've already begun fixing them in the pk-init-19.txt version.
[19:40]<kenh> jhutz: Back in Vienna, there was a significant push from certain people to get people working on pkinit, in response to that we had the interim WG meeting in Boulder, CO, to focus on some of these issues.
[19:40]<BrianTung> do people want me to recap the changes that went into pk-init-18.txt?
[19:41]<hartmans> I think Jeff is doing that now in brief detail
[19:41]<kenh> jhutz: Some issues were worked out on the mailing list, some issues worked out after Minneapolis meeting.  After we work out few remaining issues, document should be ready for last call.
[19:41]<kenh> jhutz: Remaining open issues: SubjectAltName, what should it look like?  Received comments from Brian, with proposed text.
[19:41]<BrianTung> would it make sense to run pk-init-19.txt by Russ before submitting it?
[19:42]<BrianTung> oh yes, in preparation for pk-init-19.txt, I did a little stroll down memory lane on the subjectaltname issue.
[19:42]<BrianTung> it turns out it's much older than I had remembered.
[19:42]<kenh> jhutz: Client Name Canonicalization - resolved recently on mailing list.
[19:43]<kenh> jhutz: Resolution - clients do need to include a client name in their PKINIT request.
[19:44]<kenh> jhutz: Name returned by KDC in ticket must match name requested by client.
[19:44]<kenh> jhutz: Love brought up issues about OCSP - will go back and forth on mailing list, and hopefully come up with better text.
[19:44]<raeburn> pkinit-18 goes into some kcrypto stuff that it probably shouldn't.  I'll send email...
[19:45]<BrianTung> OK, I thought we had eliminated most of that.
[19:45]<kenh> jhutz: Preauth type numbers - have agreed to change preauth type numbers at the last minute, should not be an issue.
[19:45]<kenh> jhutz: Open discussionn?
[19:45]<Eric Rosenfeld> Before pkinit-19 is submitted, I'd like to offer assistance in editorial review on the draft. Doc Evans and I can help to ensure the text is solid for a last call. Is this appropriate?
[19:46]<BrianTung> I don't see a problem with that.
[19:46]<Doc Evans> Thank you, sir
[19:46]<Eric Rosenfeld> Great. What is the timeframe for completing pkinit-19?
[19:47]<BrianTung> I'm caught up, so as soon as I get suggestions for changes, they go straight in.
[19:47]<BrianTung> that means that it's gating on the open issues, but *only* on the open issues.
[19:47]<kenh> comment from brian relayed about talking to russ; jhutz will send him email.
[19:47]<kenh> second set of slides are now up, in same place, krb-agenda.pdf
[19:48]<BrianTung> thanks, ken.
[19:48]<jhutz> eric - sounds like a good idea to me
[19:48]<jhutz> if you want you can forward a copy to me as well, so I can do my usual WG chair nits thing
[19:49]<BrianTung> I will send e-mail to eric and doc with the current state of the draft.
[19:49]<Eric Rosenfeld> OK, then can we agree on a date for resolving open issues, and handing pkinit-19 to Doc and myself, and when we should resolve editorial issues by.
[19:49]<BrianTung> and to jeff, too.
[19:49]<kenh> jhutz: One more items on agenda; hartmans will talk about preauth.
[19:49]<kenh> hartmans: apologize for lack of slides.
[19:49]<BrianTung> do we need to settle dates now, or do it through e-mail also?
[19:49]<Eric Rosenfeld> email is fine, as long as we settle dates by end of week?
[19:49]<kenh> hartmans: last meeting we decided to do work on the preauth issues I raised.  See draft (name unknown right now).
[19:50] rickravaya has left the room.
[19:50]<jhutz> some of us are getting onto long flights tomorrow.
[19:50]<kenh> hartmans: Writing down the "oral tradition" in the Kerberos community about how preauth works.
[19:50]<Eric Rosenfeld> ok, then how about next week?
[19:50]<lha> draft-ietf-krb-wg-preauth-framework-00.txt
[19:51]<BrianTung> wednesday next week: deadline for settling dates for resolving open issues, submitting draft-19 to nitpick, and then completing nitpick?
[19:51]<kenh> hartmans: Introduced concept of "authentication session" that only exists on client, which has to keep state between requests and the encryption key (which may change).
[19:51]<jhutz> I think we should be able to resolve the subjectaltname issue by the end of next week, unless there are unexpected issues.
[19:51]<jhutz> I don't know how long it will take to resolve lha's OCSP language issue.
[19:52]<kenh> hartmans: Preauth must be designed so the KDC does not need to keep state.
[19:52]<Eric Rosenfeld> ok, great. Thanks, Brian.
[19:52]<jhutz> (maybe lha can comment on that?)
[19:52]<jhutz> I'd like to settle dates now, so we can try to stay on track
[19:52]<BrianTung> is lha in seoul?
[19:52]<jhutz> yes he is
[19:53]<kenh> hartmans: Draft also talks about preauth in the Kerberos extensibility model (how to determine the other side supports a particular preauth protocol).
[19:53]<BrianTung> all right: I propose, resolve open issues by March 15; submit pk-init-19.txt to jeff, doc, eric by March 22;
[19:53]<BrianTung> when do you want to get it back to me by for final revisions?
[19:53]<kenh> hartmans: Preauth draft also discusses the kind of state in a preauth request; this may be obvious to us, but is not written down anywhere.
[19:54]<jhutz> It should not take me more than a couple of days to do nits; it's partly automated.  Eric? Doc?
[19:54]<kenh> hartmans: Had a meeting with Love, it turned out that we had fairly similar ideas.
[19:54]<Doc Evans> March 29
[19:54]<BrianTung> we also need love's input on how long ocsp will take to resolve.
[19:54]<BrianTung> fine by me.
[19:54]<jhutz> So, resolve issues by mar 15, doc ready for nits by 22, nits back by 29?
[19:54]<Eric Rosenfeld> sounds great.
[19:55]<raeburn> I'd also like to nitpick -19 for crypto stuff.  (Email on its way to Brian shortly.)
[19:55]<BrianTung> pending love's input, ok by me.
[19:55]<jhutz> ... then it gets submitted to i-d repository by what date?  mar31 if there are no major changes?
[19:55]<BrianTung> OK, ken.  do you think it's going to be time-consuming, or mostly just excising?
[19:55]<BrianTung> (to jhutz) apr 2.
[19:55]<kenh> hartmans: Example: A KDC could support PKINIT or hw-preauth w/ SecurID.  There is no way for the KDC to indicate combinations; we would like to declare this problem out of scope - solving this problem is very hard.
[19:55]<lha> [brian: I don't know, the text as is was proposed by Jaganathan was ok]
[19:56]<jhutz> OK; apr 2.  And then I'll last call when it appears in the repository.
[19:56]<BrianTung> [to love] so it's your contention that I copied it poorly?  that's fine.
[19:56]<kenh> hartmans: Another issue: authentication of request/replies, especially with multiple round-trip messages.
[19:56]<BrianTung> I was editing as I copied it in, so I probably messed stuff up.
[19:56]<raeburn> Mostly excising.  Maybe moving a little text around.
[19:56]<lha> [brian: but it assumes that the assumptions that Jaganathan makes are ok]
[19:56]<kenh> hartmans; Need to discuss what is used as nonces.
[19:56]<BrianTung> [to ken r] OK, hope it's easy.
[19:57]<larry> hello, we are JK and Larry from Microsoft, we have some concerns over the cname requirement, but we will raise in the list
[19:57]<raeburn> Should be.
[19:57]<kenh> hartmans;: If things are easier if an issue is deferred until extensions is ready, I would rather do that.
[19:57]<jhutz> brian, do I need to ask Russ to take a look at this?  Will -18 be sufficient for that purpose?
[19:57]<BrianTung> [to love] you have reason to think they might not be valid assumptions?
[19:57]<jhutz> If so, can you send me mail with the details, and I'll forward it on to him?  I'd rather not have our schedule assume Russ is going to review a document in a week
[19:57]<kenh> hartmans: Things that can be made to work with clarifications, I would like to do them.
[19:57]<BrianTung> [to jeff] no, because the subjectaltname stuff is punted (or perhaps just done wrong) in pk-init-18.txt
[19:57]<lha> [brian: is static configration ok of responder id ok]
[19:58]<kenh> hartmans: New draft coming out now, please read it, comments/questions?
[19:58]<jhutz> larry/JK; if you stick around until the end of sam's presentation, we can bring it up at open mic
[19:58]<larry> sure
[19:58]<kenh> love: Would we want to use a new specifications of nonces in other preauth mechanisms, or just make them available for other preauth mechanisms?
[19:59]<jhutz> also is there anything you want to say about the referrals document?
[19:59]<BrianTung> [to love] I don't think I followed your last remark.
[19:59]<kenh> hartmans: I hope preauth document will be useful in clarifications universe, and not be broken in an extensions universe.
[19:59]<kenh> I might have transcribed his comment poorly.
[19:59]<jhutz> Is subjectaltname the only thing you want russ to review now?
[19:59]<larry> we would like to see more input from the wg on the referral draft
[20:00]<BrianTung> [to ken h] no, I was talking about his direct remark to me.
[20:00]<kenh> hartmans; I have received enough comments from people that want this work, so I would rather not defer it until extensions.
[20:00]<BrianTung> "is static configuration ok of responder id ok"
[20:00]<kenh> brian - okay, understood.
[20:01]<BrianTung> [to jeff] it's certainly the thing that is in the most flux, so yes.
[20:01]<lha> [brian: ocsp assume local static configuration of preauth responders on clients, if responders id change, how should the clients know ?]
[20:01]<hartmans> Larry looking at referals is fairly high on my priority list
[20:01]<kenh> jhutz: If there are no comments on Sam's presentation, would like to move into open mic portion.
[20:02]<kenh> jhutz: Anything else anyone wants to bring up?
[20:02]<jhutz> now is the time to bring up your comment, larry
[20:02]<larry> client configuration changes can be preformed via policy (for OCSP responder-ids)
[20:03]<jhutz> we're going to take cname offline, then
[20:03]<kenh> jhutz: OCSP discussion will be taken to list.
[20:03]<jhutz> any other comments?
[20:04]<BrianTung> larry, you do not want to raise your cname concerns here?
[20:04]<larry> sure
[20:04]<kenh> jhutz: looks like we're done, we will see you all in san diego
[20:04]<warlord> wow, that was quick!
[20:04]<BrianTung> that *was* quick.
[20:04]<kenh> yeah, you're not kidding.
[20:04]<larry> are you waiting for us?
[20:05]<larry> we would like to keep the cname as OPTIONAL
[20:05]<raeburn> Interesting that half the participants (or more?) were *only* participating remotely...
[20:05]<jaltman> any reason for an interim meeting?
[20:05]<kenh> jeff says that no, he's not waiting for you, larry.
[20:05]<jhutz> "keep"?
[20:06]<larry> what is "keep"?
[20:06]<BrianTung> [to jhutz and larry] the draft as it is in pk-init-18.txt is *unclear* and/or inconsistent.
[20:06]<BrianTung> one can infer it is optional, but nowhere in pk-init-18.txt does it explicitly state that one can omit the cname.
[20:06] jas has left the room.
[20:06]<jhutz> the cname is OPTIONAL only from a syntactic standpoint.
[20:06]<jhutz> it is always present in AS-REQ, and never in KDC-REQ
[20:07]<Doc Evans> Excatly
[20:07]<BrianTung> and it does state that the as-req is otherwise unchanged.
[20:07]<larry> no, that is not necessarily true for PKINIT
[20:07]<larry> as shown in our PKINIT implemenation
[20:07]<Doc Evans> How do you come to that conclusion?
[20:07]<larry> how does the client know the cname?
[20:08]<Doc Evans> How do you conclude that any current text allows you to drop the cname?
[20:08]<larry> KDC-REQ-BODY    ::= SEQUENCE {
              kdc-options             [0] KDCOptions,
              cname                   [1] PrincipalName OPTIONAL
                                          -- Used only in AS-REQ --,
              realm                   [2] Realm
[20:08]<Doc Evans> Right...
[20:08]<Doc Evans> but...
[20:08]<larry> it does not say it is required
[20:09]<Doc Evans> the intent has always (I believe ) that that should be interprted to mean that it must be present in an AS-REQ
[20:09]<tlyu> this sort of ambiguity is one of the reasons i wanted to use quite a few additional ASN.1 constraints in extensions
[20:09]<Doc Evans> I do agree in principle, though
[20:09]<Doc Evans> But not in practice
[20:09]<jhutz> it is optional from a syntactic standpoint, because the same message is used for AS-REQ and TGS-REQ.
[20:09]<Doc Evans> Right
[20:09]<BrianTung> but the root issue is that you want it in because the client might not know the right cname to put in the request.
[20:09]<Doc Evans> Which was a mistake in RFC 1510 
[20:09]<jhutz> It is actually the case that cname is always present for an AS-REQ, and always absent for a TGS-REQ
[20:09]<larry> brian is with us
[20:10]<BrianTung> [to larry] ???
[20:10]<BrianTung> you mean I understand your concern?
[20:10]<larry> w.r.t.
[20:10]<tlyu> are we going to have to invent another "magic" principal name?
[20:10]<jhutz> See the description of the AS exchange in 3.1, particularly the next-to-last paragraph on page 24 of clarifications-05
[20:10]<larry> yes
[20:10]<BrianTung> well, now, hold on.
[20:10]<larry> brian: yes
[20:12]<BrianTung> I'm not sure exactly how to answer that question, but the name canonicalization issue is a thorny one.
[20:12]<larry> correct, we are trying to give you some input w.r.t. cname canonicalizations
[20:13]<BrianTung> you know there have been a host of name canonicalization proposals that have been problematic.
[20:13]<raeburn> (a "host" of them? ow.)
[20:13]<BrianTung> well, ok, host is overstating it.
[20:14] tomphelan has entered the room.
[20:14]<BrianTung> my concern is that the problem has been looked at previously and still lacks a definitive solution.
[20:15] tomphelan has left the room.
[20:15]<larry> we seems to be overtime, we can take this to the list
[20:16]<warlord> overtime?
[20:16]<warlord> there's another 1:15 left in this timeslot
[20:16]<larry> it is supposed to be 1 hour, right?
[20:16]<BrianTung> no, no, we have from 9:00 to 11:30, don't we?
[20:16]<BrianTung> that's 4:00 to 6:30 pst.
[20:16]<Doc Evans> I have to leave. Bye.
[20:16]<BrianTung> I have to split in about 15 minutes or so.
[20:16]<BrianTung> bye doc.
[20:16] Doc Evans has left the room.
[20:17]<larry> short of requiring that every client certificate contain a cname the only other option is to do canonicalization
[20:18]<larry> either at the client or the KDC
[20:18] BCNeuman has left the room.
[20:18]<BrianTung> or to do some kind of cname discovery.
[20:19]<BrianTung> obviously, if the cert doesn't contain the cname, the kdc will have to do some kind of transformation, if only to determine the name to check against the cname in the request (if any).
[20:19]<BrianTung> but I'm wary of prescribing exactly what that transformation should be.
[20:19]<larry> we dont want to prescribe anything either
[20:20]<BrianTung> then I'm unclear about what you're proposing to do.
[20:20]<larry> only that the cname remain optional so the mapping can be done at the KDC
[20:20]<BrianTung> is nico around anywhere?
[20:20]<kenh> I don't think he's here.
[20:20]<tlyu> i'm not sure that cname in an AS-REQ can really be considered optional, given wording in rfc1510, clarifications, etc.
[20:20]<raeburn> Unless you allow the presenter of certain certs to identify themselves as any of several principals.  Then the KDC needs to *not* be doing a transformation, but an access check.
[20:21]<BrianTung> because nico raises the point that the cname in the reply is unsigned.
[20:21]<raeburn> E.g., cert for raeburn -> raeburn <at> ATHENA, raeburn/test <at> ATHENA, etc.
[20:21]<raeburn> Or is that already not permitted by the model?
[20:21]<raeburn> (Sorry, hadn't thought about it until the KDC-side transformation was mentioned, and haven't checked...)
[20:22]<BrianTung> you mean, make sure the proffered cname is authorized to that cert?
[20:22]<tlyu> nico's point is a good one... though you might be able to hack around it by including a signed cname in the reply in preauth somewhere
[20:22]<raeburn> Yeah, something like that.
[20:22]<BrianTung> that still requires the cname in the request, though, ken.
[20:22]<jaltman> personally I think clients certs should have a principal assigned to them as a subjectAltName.  However, I believe that we agreed that we wanted the mapping of Certificate to principal to be performed at the KDC under an administrator determined policy.
[20:23]<tlyu> i'm not sure i like the idea of the KDC doing authorization checks, but that seems to be an inherent part of doing pkinit
[20:23]<BrianTung> tom, we have considered that previously.  it might still happen.
[20:23] omarjan has entered the room.
[20:23]<BrianTung> jeff, that's the first option; the kdc can always choose to take the subjectaltname in the cert.
[20:23]<tlyu> brian, which? the signed cname in preauth?
[20:24]<raeburn> Yes, it does.  But it doesn't work with the model that the KDC can do a transformation to get the one cname permitted.  Which may mean my idea is wrong, or may mean that that model for the KDC is wrong.
[20:24]<BrianTung> it's either choosing the name, or authorizing the name.
[20:24] omarjan has left the room.
[20:24]<BrianTung> for the moment, we've decided that it should be authorizing the name.
[20:24]<jaltman> Clearly, if there is a subjectAltName in the cert, then the client should be using that as the "cname"
[20:24]<BrianTung> jeff, you think the order in the draft is inappropriate?
[20:24]<BrianTung> I'm open to that.
[20:24]<BrianTung> tom, yes.
[20:25]<Eric Rosenfeld> I have to go. I look forward to the meeting notes on this issue.
[20:25] ddp has entered the room.
[20:25]<jaltman> Eric, wait please
[20:25]<Eric Rosenfeld> Yes?
[20:26]<jaltman> are you placing subjectAltNames in your certificates?
[20:26]<BrianTung> actually, I think subjectAltName, then local mapping makes better sense than the other way around...
[20:26]<jaltman> (for the client)
[20:26]<Eric Rosenfeld> Not for the client.
[20:26]<jaltman> Thank you.  That is what I needed to know.
[20:26]<jaltman> Brian, yes, the ordering should be swapped.
[20:27]<BrianTung> I'll note that, thanks jeff.
[20:27]<Eric Rosenfeld> You're welcome. Catch you all on the reflector.
[20:27]<jaltman> If there is a subjectAltName in the client certificate specifying the client principalName then its contents should be used for the cname in the AS_REQ.  And it should be used by the KDC as the principal name.
[20:27] Eric Rosenfeld has left the room.
[20:28]<BrianTung> yes, we've all agreed the names must match.
[20:28]<BrianTung> that doesn't solve ms's problem, though.
[20:28]<tlyu> can you describe succinctly what the ms problem is?
[20:28]<DougEngert> Are you assuming that the certificates being used where issued with Kerberos in mind?
[20:28]<larry> our problem occurs when there is no subaltname
[20:28]<raeburn> Hm, on reflection, I suppose it makes sense to require a different cert for a different cname owned by the same person...
[20:29]<jaltman> We are still left with the question of what to do when there is no subjectAltName.   There are two choices.  Place a magic name which will be replaced by the KDC.  Or require the client to perform a Certificate to Principal Name mapping before preforming the AS_REQ.
[20:29]<DougEngert> The Subject Altname may have been set for some other use.
[20:29]<BrianTung> they want to allow the kdc to determine the mapping (not verify it) in cases where the client cannot reasonably be expected to know it in advance, I guess.
[20:29]<BrianTung> there can be more than one subjectaltname, can't there?
[20:29]<jaltman> The subjectAltName will not be a kerberosPrincipal if it were not set for use by Kerberos.
[20:30]<BrianTung> we just want to make sure there is only one kerberos principal name encoded as such in a subjectaltname.
[20:30]<BrianTung> larry, is that basically right?
[20:31]<larry> let me try to succintly outline our requirements
[20:31]<DougEngert> A  user could use one cert with unrelated realms, so the subjectAltName may not match either.
[20:31]<larry> we cannot depend on subaltname being present in the cert
[20:32] kenh has left the room.
[20:32]<jaltman> I believe that MS wants to be able to use a certificate issued for a purpose other than Kerberos to be used for a Kerberos exchange.  In this case, they are keeping a database of the certs which is accessible to the KDC.  The KDC receives a certificate and either looks up a hash of the cert or something else in the database and gets back a principal name.
[20:32]<larry> and even if it did we cannot always require that it should be the name to be used
[20:32]<larry> that is sort of the case
[20:33]<DougEngert> A agree with Larry.
[20:33]<tlyu> larry, are you allowing for a situation where the client is unaware of the mapping the KDC uses?
[20:34]<BrianTung> I think that is exactly the problem.
[20:34]<larry> exactly.. that is the case we want to allow
[20:34]<BrianTung> what if the client_name_mismatch error carried a hint with the right name to use?
[20:34]<larry> because maintaining that mapping at the client will be very expensive
[20:34]<BrianTung> currently there is no e-data with the client_name_mismatch error.
[20:35]<jaltman> In this situation, we have to accept that client principal name canonicalization is going to take place.  To stay within the spec a dummy name must be placed in the cname field.  An error will occur and following Brian's train of thought the KDC must tell the client what name should be used.
[20:36]<tlyu> of course the KDC will have to return a preauth-required error, since padata in e-data aren't specified for anything else.  yuck.
[20:36]<larry> this will mean that all our clients will need two round trips for each logon
[20:36]<jaltman> An alternative mechanism for MS is to have the host perform a protocol operation to map the Cert to the Client Principal which is secured by the Host principals.
[20:36]<larry> why not just let the KDC issue the TGT?
[20:36]<hartmans> Requiring the extra round trip doesn't buy you anything.  This is a security issue and the error won't be secured either
[20:37]<BrianTung> tom, I don't think I quite follow.
[20:37]<hartmans> I think what needs to happen here is that I need to read referals.
[20:37]<hartmans> I'll either come to the conclusion we have a global security problem both with pkinit or we have no security problem at all.
[20:38]<hartmans> both with pkinit and referals that is.
[20:38]<tlyu> e-data aren't specified except for a small number of errors
[20:38]<BrianTung> ok, I was just going to ask where the "both" was binding.
[20:38] rlbob has left the room.
[20:38]<BrianTung> we specify a bunch for pkinit.  is that bad?
[20:38]<hartmans> Yeah.  Tom has a point; there's not really a way to add a hint to an error in standards-track clarifications.
[20:38]<tlyu> are they for existing errors or for new errors?
[20:38]<BrianTung> sam, you've raised this previously, haven't you?  the issue that the reply isn't signed?
[20:39]<BrianTung> for new errors, tom.  client_name_mismatch is a new error.
[20:39]<hartmans> N I raised the general issue.  We weren't sure that was bad.
[20:39]<BrianTung> isn't it?  I thought we defined it for pkinit?
[20:39]<BrianTung> or did I misremember?
[20:39] ddp has left the room.
[20:39]<hartmans> This is a specific issue of something in the reply not being signed; we're not sure it is bad
[20:39]<BrianTung> N I?
[20:40]<hartmans> O, if it is a new error, you could add the hint.  But as Larry points out it adds a round trip and doesn't buy you anything from a security standpoint
[20:41]<BrianTung> I'll check to see if it's a new error.
[20:41]<hartmans> But I'm certain this is not a pkinit  issue; this is just client name canonicalization
[20:41]<BrianTung> but your point is taken.
[20:41]<hartmans> Well, and what to stick in the cname field
[20:41]<jaltman> .the initial cname field is going to have to hold a dummy name
[20:41]<DougEngert> How about "whoami"
[20:42]<BrianTung> heh heh.  the exact contents of the dummy name aren't important, I don't think...
[20:42]<raeburn> cname of "who-the-heck-am-i", which canonicalizes to any of ten thousand names depending on additional data in preauth..
[20:42]<jaltman> jane.doe
[20:42]<hartmans> How about the same dummy name we decided on as an extensions probe.
[20:42]<tlyu> i am having trouble finding the dummy name we decided on
[20:42]<hartmans> Check the boulder minutes.
[20:43]<BrianTung> so then what.  the as-req gets sent with some dummy name (TBD), then the KDC performs its mapping and determines the real principal name to use.
[20:43]<jaltman> pretty much
[20:43]<BrianTung> nico asks how the client can trust the name in the reply?
[20:43]<jaltman> the reality is that it can't
[20:44]<jaltman> which is why the certificate should have a subjectAltName containing a kerberosPrincipal
[20:44]<hartmans> Right.  And I know I'm not going to be convinced about security or insecurity in a real-time discussion.   Which doesn't mean don't have the discussion if it will help others, but I'll consider this issue open until I read and think about extensions.
[20:44]<BrianTung> it can't, signed or unsigned, isn't that so?  as long as the kdc determines the mapping, it doesn't really matter whether any part of the reply is signed, the client has to take the kdc's word for it.
[20:44]<hartmans> Taking the KDC's word might be better than Malary's.
[20:45]<BrianTung> malary?
[20:45]<hartmans> Person in the middle
[20:45]<jhutz> random evil attacker who sends you an unsigned response
[20:45]<BrianTung> ahh, right.
[20:45]<warlord> malary is an active attacker
[20:45]<jaltman> Malary is my middle name (jk)
[20:45]<warlord> Heh
[20:45]<BrianTung> we used a different name, I don't remember which...
[20:45]<warlord> Eve?
[20:46]<BrianTung> yes, eve, but I don't remember if eve was mitm.
[20:46]<warlord> (passive attacker)
[20:46]<tlyu> eve is typically passive
[20:46]<tlyu> mallory or mallet are active attackers
[20:46]<warlord> eve -> evesdropper
[20:46]<BrianTung> ANYWAY...
[20:46]<BrianTung> I'll see how much work it would be to sign the name in the reply.
[20:46]<jhutz> anyway, the key point is whether it matters that the cname in the reply is unsigned and therefore cannot be
[20:46]<jhutz> trusted by the client.
[20:47]<BrianTung> I really have to go.
[20:47]<jhutz> Let's take this to the mailing list.
[20:47]<BrianTung> I should have become a pumpkin about 15 minutes ago.
[20:47]<tlyu> i can't find the "magic" principal name in the boulder minutes
[20:48]<tlyu> can someone please extract it and send to the mailing list?
[20:48]<jaltman> are the jabber ietf rooms available during the off season?
[20:48]<BrianTung> yes, this is useful.
[20:48]<BrianTung> (I mean yes, I agree with your question, I don't know if they're available.)
[20:48]<raeburn> I believe they are.
[20:48]<raeburn> Brian: My crypto notes are on their way to you.
[20:48]<jhutz> Note that in extensions, the as-rep will be signed, including the cname
[20:49]<BrianTung> ok, I'll take a look at them tomorrow, probably.
[20:49]<BrianTung> buh bye.
[20:49]<jhutz> yes, they are always available
[20:49] BrianTung has left the room.
[20:49]<jaltman> cool, then there is only a security hole for clarifications.  maybe this is a reason for MS to implement extensions
[20:49]<hartmans> Thanks for your time
[20:50]<tlyu> i also need to leave soon

[20:51]<jhutz> I think folks need to review the referrals draft, and decide whether it's a problem at all.
[20:53]<larry> the client name is going to protected in the referral info
[20:53]<larry> the existing MS implementation does not use the unsigned field
[20:53]<jhutz> "referral info"?
[20:53]<larry> but use the ones in the PAC
[20:54]<larry> I think I mixed it up,  the referral-info contains the server infomation
[20:54]<larry> not the client
[20:54]<jhutz> In extensions, the cname in the reply will be signed.  So as part of doing referrals, we can make the cname in the AS-REQ explicitly optional in that protocol.
[20:54]<larry> this is not a concern for us because of the PAC
[20:54]<larry> but we should address it in the referral draft
[20:54]<jhutz> But the PAC is a MS extension and not part of the base kerberos protocol
[20:55] tlyu has left the room.
[20:55]<larry> that is correct, we should address this in our next version
[20:55]<jaltman> I am fairly sure it is a problem for CableLabs
[20:56]<jhutz> Which means that any extensions client could send a request with no name, and let the KDC choose a name based on preauth (pkinit or otherwise) or whatever.
[20:56]<jhutz> But a clarifications client, even using pkinit, would have to include a cname because clarifications requires that.
[20:56]<jaltman> right
[20:57]<larry> I still did not find the exact text why clarifications require cname
[20:57]<jhutz> Now.  _iF_ it turns out we decide not having the cname in the reply be signed is not a problem, then we can allow "no cname" with pkinit in clarifications, by using a dummy name.  But net's not worry about whether/what dummy name we need until we decide it is safe.
[20:57]<jhutz> I referred to it...
[20:57]<larry> not convinced
[20:57]<jhutz> "In the request, the client sends (in cleartext) its own identity...."
[20:58]<jaltman> Clarifications - 05 Page 24 second to last paragraph coupled with the behavior of existing implementations not including MS and the fact that without a signed object to return the client principal name it there is a security hole.
[20:59]<jhutz> If you think clarifications is not sufficiently clear on this, there is still time to fix it.  But it's pretty clear to me that that was the intent.
[21:00]<jaltman> the text does not say "the client may send its principal name in the cname field", its says "it will ...."
[21:00]<jaltman> to me that is a "MUST"
[21:00]<jhutz> We can change it to say "the client MUST send" instead of "the client sends"
[21:01]<jaltman> I agree we should submit that change after vetting it on the list.
[21:01]<larry> In the request, the client sends (in cleartext) its own identity
      and the identity of the server for which it is requesting
      credentials, other information about the credentials it is
      requesting
[21:01]<jhutz> Yes; that's the text we're reading
[21:01]<larry> the client can send it identity via pre-auth
[21:01]<larry> not necessary via cname, right?
[21:01]<jaltman> Larry, are there other circumstances other than PKINIT in which the MS implementation does not specifiy a cname?
[21:01]<jhutz> That's not the intent of that text, no
[21:02]<larry> in fact, existing MS implementation always sends cname
[21:02]<larry> even for PKINIT
[21:02]<jaltman> Even if the identity is sent via-preauth, it must still include a copy of its principal name in the cname field
[21:02]<larry> but we are adding new features
[21:02]<larry> having cname required is going to be problematic
[21:02]<jhutz> nonetheless, it has always been required
[21:03]<jhutz> we can make it optional in extensions, pretty easily.
[21:03]<jhutz> it's still unclear to me whether the intent of the WG is that it be possible to do referrals against clarifications.  I didn't think so, but now I'm hearing otherwise.
[21:04]<jaltman> the answer was "no" but there was an "exception for pkinit" made in Boulder.
[21:04]<hartmans> As the person who caused Jeff to hear otherwise, my understanding is that nothing in the current referals document  is extensions-specific.
[21:05]<jhutz> _If_ that is the intent, and _if_ the WG determines that there is no security problem with allowing cname canonicalization with the cname not signed in the reply (in the general case, not just if you happen to also use a non-IETF extension), _then_ we can make the cname "optional" in referrals by using a dummy name.  But it will offend my sense of aesthetics
[21:05]<larry> that is my understanding too
[21:05]<larry> we can secure the cname via the referral info
[21:06]<larry> we can add this to the PA_DATA in kdc reply, right?
[21:06]<hartmans> I'm not willing to agree to anything;  The issue is too complex.  But yes it sounds like you are correct
[21:06]<jaltman> I should also clarify the "exception" by stating that there would be a commitment by those implementing PKINIT to deploy Extensions as soon as possible in order to deal with internationalization and referals issues.
[21:07]<hartmans> But really we're ratholed fairly significantly.  Let's determine if we have a problem on pkinit before solving it.
[21:08]<hartmans> *craves lunch*
[21:10]<warlord> mmm. lunch...   after marid.
[21:11]<DougEngert> Bye
[21:11] alexeymelnikov has left the room.
[21:11] DougEngert has left the room.
[21:12] hartmans has left the room.
[21:12]<warlord> later.
[21:12] warlord has left the room.