Subject: IETF krb-wg Jabber log

From: Jeffrey Altman <[email-masked]>
Date: Wed, 03 Mar 2004 20:51:38 -0500

[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@ATHENA, 
raeburn/test@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

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 03 Mar 2004 21:14:02 -0500

[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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 04 Mar 2004 11:38:12 +0900

The jabber logs are in fact available on the web, at

http://www.xmpp.org/ietf-logs/[email-masked]/2004-03-03.html

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Mar 2004 01:17:05 -0600

Wow -- this was a busy meeting!

There's a lot here to digest, and some items for me to address.  I'll
try to get to it tomorrow.

Briefly though, on the cname field of AS-REQs:

 - I believe it is to be required, always, in AS-REQs...

 - ...but I offered some alternatives should the KDC-figures-out-my-
   princ-name-from-my-cert feature be really desireable...

 - ...and I explained that without any additional steps this feature
   leaves the client open to an active attack (that perhaps we don't
   care about if every cert a KDC recognizes maps to one and only one
   princ name -- this was one of the options I offered).

 - The alternatives I offered stand, and, as discussed at the meeting, a
   pre-auth type to sign the AS-REQ in the AS-REP would be one
   possibility.  In extensions we should not only pursue Signed, but
   also try to ensure that every reply signs the corresponding request.

More later.

Nico
--

---

From: "D. R. Evans" <[email-masked]>
Date: Thu, 04 Mar 2004 10:12:39 -0700

I just want to say how impressed I am at how well the jabber-chat 
session worked.

I was skeptical beforehand (about the idea of a chat session; not about 
jabber - I have used that for ages), but I really thought that it worked 
very, very well.

It might have helped if people could have used nicknames that identified 
them a bit better, but maybe not all clients allow that when joining a 
groupchat.

Just for reference, it might be nice if people were to log into the same 
chatroom and leave their JIDs (which others could then read by looking 
at the logs for the next few days). I don't know how to reach most of 
you except by e-mail, and it seems like it might be helpful for us all 
to know one another's JIDs.

Now back to your regularly-scheduled programming....

   Doc

-- 

-----------------------------------------------------------
Phone:  +1 303 494 0394
Mobile: +1 720 839 8462
Fax:    +1 781 240 0527
-----------------------------------------------------------