[06:02:31] --- mrex has joined
[11:16:48] --- krb-wg has joined
[11:50:03] --- semery@jis.mit.edu has joined
[11:52:00] --- sommer@jabber.cc has joined
[11:52:39] --- ietf-meeting has joined
[12:00:43] --- jhutz has joined
[12:01:13] <jhutz> Welcome.
[12:01:31] <jhutz> The audio stream for this session is at http://tinyurl.com/2karj7
[12:01:37] --- Alexey has joined
[12:01:38] --- tlyu@jis.mit.edu has joined
[12:01:48] <jhutz> Meeting materials are at http://tinyurl.com/2jwtgj
[12:02:07] <jhutz> And there is a public (read-only) VNC server showing the slide projector at ietf-vnc.central.org
[12:02:22] <krb-wg> Hi
[12:02:56] <Alexey> I will try to scribe
[12:03:19] --- lha has joined
[12:03:57] --- krb-wg has left
[12:04:35] --- hbhotz has joined
[12:05:10] <Alexey> We are starting
[12:05:27] <Alexey> welcome speech from jhutz
[12:05:42] <Alexey> Slides are in the usual place
[12:05:55] --- nico has joined
[12:06:03] --- he has joined
[12:06:13] <Alexey> jhutz: Side note: mailing list software for the WG changed
[12:06:32] <Alexey> Document status next
[12:07:17] --- hartmans@jis.mit.edu/owl has joined
[12:07:34] --- guenther has joined
[12:07:50] <Alexey> 3 technical discussions to follow
[12:08:16] <Alexey> and milestone review
[12:08:34] <Alexey> Agenda bashing
[12:09:25] <Alexey> If we have extra time for Shawn's document, will do this at the end
[12:09:33] <Alexey> ECC PKINIT in AD review
[12:10:03] <Alexey> Set/Change Password: jhutz sent some comments to the document author, but got no reply from the author/WG
[12:10:21] <Alexey> Data Model document is Almost ready
[12:10:30] <Alexey> Leif missed the deadline
[12:10:33] <nico> you did?
[12:10:35] <jhutz> is the audio working?
[12:10:52] <nico> oh, yes
[12:10:54] <nico> on the list
[12:11:01] <nico> I'll respond
[12:11:10] <Alexey> Leif will publish draft-ietf-...-00
[12:11:14] <Alexey> Reviews are needed
[12:11:32] <Alexey> 3 documents in LC
[12:11:50] <Alexey> "Anonymous" LC ended on November 21
[12:12:05] <Alexey> Some comments from jhutz, several others as well
[12:12:13] --- ShoichiSakane has joined
[12:12:24] <Alexey> GSS Hash Agility WGLC ended on December 6
[12:12:49] <Alexey> Cross Realm Problem WGLC will end on December 14. Feedback needed
[12:13:51] <Alexey> Shawn: comments received privately on increasing the size of private use set (GSS Hash agility)
[12:16:16] <Alexey> (GSS Hash) jhutz commented to Shawn that IESG approval is too restrictive
[12:17:14] <Alexey> Sam: if there is no review for mechanisms, at least some guidelines are needed (for interop)
[12:17:51] <Alexey> Sam would like to understand why private use is desirable
[12:18:35] <nico> hmmm
[12:19:17] <nico> couldn't IAKERB prefix its hash of prior messages to the app's channel binding data?
[12:19:29] <nico> that would avoid that issue
[12:19:46] <jhutz> nico, there's no issue; it's just an example of an extension
[12:20:16] <Alexey> Sam as an individual is incomfortable with private use
[12:20:26] <nico> ok, but it seems like an unnecessary extension
[12:20:36] <nico> Larry: that would be the same thing
[12:20:43] --- finn- has joined
[12:20:55] <nico> can't we defer the puc discussion to the day that someone actually has a need for it?
[12:21:22] <Alexey> Paul Hoffman: every time we didn't have private use in protocols, we regretted it. Private use is great for experimental purposes (e.g. when people not sure if they got it right)
[12:21:35] <jhutz> well, no. we have to set the registry policy now, when we create the registry.
[12:22:37] <nico> jhutz: you can always change it
[12:22:54] <mrex> If private use isn't defined, it is still going to happen, just arbitrary
[12:23:19] <Alexey> Sam: just have 2-3 codepoints for experimental, so that people can't be sure it wouldn't collide
[12:23:33] <nico> we don't even envision any GSS-API extensions that would allow the app to make use of any of these extensions
[12:23:54] <nico> so if PUC wouldn't be for vendors, then who the heck would it be for?
[12:24:01] <nico> not for GSS-API apps
[12:24:04] <mrex> e.g. GSS-API doesn't have private-use context attributes, still some implementations use them (drawing bits from the other end of the bit-set of context attributes in the C-Bindings)
[12:24:20] <nico> mrex: what?!
[12:24:22] <nico> ew
[12:24:58] <nico> slotf for new things
[12:25:03] <nico> slots for new things
[12:25:15] <jhutz> folks, if you're going to respond to the audio in jabber, try to include enough context that those of us hearing it real-time understand you
[12:25:17] <Alexey> Paul Hoffman: is in favour of Sam's idea to allocating very small number for experiments
[12:26:07] <nico> ok
[12:26:39] * nico supports experimental codes, but not PUCs
[12:26:43] <Alexey> Some confusion about what this document is for
[12:27:03] <nico> a small namespace of experimental codes
[12:27:10] <nico> yes, yes, we do
[12:27:13] <nico> sorry, context
[12:27:23] <nico> yes, we want to preserve the criticality flag
[12:27:27] <nico> and Sam needs a mic
[12:27:32] <hbhotz> can't hear, please repeat
[12:28:15] <Alexey> Sam: why criticality is needed? ("please break interop")
[12:28:35] <Alexey> Larry: tell the other end not to ignore channel bindings
[12:28:41] <semery@jis.mit.edu> I thought Nico had an argument not to use the criticality flag?
[12:28:42] <mrex> criticality is more like "go away if you're legacy installed base"
[12:29:05] <nico> semery: to me the flag says "use new AP-REP" reply
[12:29:29] <nico> sam: I think I'd like a typed hole in AP-REP for the server to confirm the channel bindings
[12:29:56] <Alexey> jhutz: the base document defined all extensions fields as optional
[12:30:30] <nico> jhutz: ah, OK, fine, get rid of the criticality flag
[12:30:33] <Alexey> Sam: BTW, should the MIC cover the mechanism OID?
[12:30:41] <nico> sam: yes, I'd like to fix that
[12:30:44] <Alexey> Sam is worried about substitution attacks
[12:31:16] <tlyu@jis.mit.edu> unless someone finds a preimage for an MD5 of all ones
[12:31:24] <nico> we might as well add the mech OID to the checksum field as an extension now
[12:31:52] <nico> tom: that wouldn't be useful
[12:32:14] <Alexey> Sam: if we do criticiality, we need to do this now
[12:32:33] <nico> sam: is right
[12:32:40] <nico> as is jhutz
[12:33:19] <Alexey> Sam doesn't understand the use case
[12:33:51] <nico> and then try again
[12:33:59] <semery@jis.mit.edu> I remember on why it wasn't desired: applications have their own policy on whether channel bindings is required or not.
[12:34:05] <nico> it's break interop then re-think and try again
[12:34:37] <lha> lets move on
[12:34:37] <Alexey> Sam: add a new error code for reporting what wasn't understood
[12:34:48] <nico> I think this is settled
[12:34:56] <nico> but what of the AP-REP typed hole?
[12:35:50] <mrex> The GSS-API architecture currently requires the implementations to establish a security context even if it does not meet the desires/expectations of the caller, and expects the caller to check attributes/characteristics of the established security context and decide whether or not to continue
[12:35:52] <Alexey> Philip G.: is this similar to LDAP extensibility which also has criticality flag?
[12:36:15] <mrex> But this is mainly about context attributes, not really about Channel bindings
[12:36:35] <Alexey> jhutz: Kerberos is different, as there are no nobs for control
[12:36:49] <Alexey> Next item: Preauth Framework
[12:37:59] <Alexey> Sam is presenting
[12:38:29] <nico> sound cut out
[12:38:41] <nico> ah, it's congestion on my side
[12:38:43] <jhutz> I turned it down a bit, then back up some. Is it still too low?
[12:38:50] <nico> it's back
[12:38:57] <nico> it was perfect, so leave it alone
[12:40:37] <Alexey> The client currently can't tell the server which authentication set to use. This doesn
[12:41:05] <Alexey> 't work for the case of many similar mechanisms (e.g. multiple SecurId servers)\
[12:41:47] <nico> heh
[12:41:53] <nico> deja vu
[12:42:05] <nico> (OID sets in the GSS-API :)
[12:42:07] <Alexey> Group: suggestion to rename pa-set to pa-sequence
[12:42:53] <nico> echo back a number
[12:42:55] <Alexey> Larry (as individual): the client echoing the sequence is simple to implement
[12:43:12] <nico> much easier
[12:43:15] <Alexey> Sam: sequence or a number from the sequence (so that there is no need to decode twice)
[12:44:09] <nico> well, if the KDC has to work out what the number is from decoding state in a state cookie, then it's no simpler for the KDC
[12:44:12] <jhutz> Hm. No one is using the VNC. Maybe it wasn't worth doing
[12:44:17] <Alexey> Sam explains why number is slightly better
[12:44:17] <nico> but a number is still simpler for the client
[12:44:36] <Alexey> Sam doesn't care that much
[12:44:51] <nico> jhutz: VNC was great at KITTEN
[12:45:03] <nico> what's on your VNC now?
[12:45:07] <lha> vnc doesn't work
[12:45:10] <nico> were my comments channeled?
[12:45:15] <Alexey> Moving on to Referrals
[12:45:37] <lha> nico: yes, your comments where tunnelned
[12:45:44] <semery@jis.mit.edu> nico: yes, alexey channeled you
[12:45:52] <hbhotz> VNC is not published on the agenda. Didn't know it existed.
[12:46:08] <Alexey> Ken missed the submission deadline
[12:46:28] <Alexey> Pending changes in version 10:
[12:46:28] <jhutz> I mentioned it in here at the start. It was a last-minute thing.
[12:47:09] <Alexey> added an optional time field for when information expires (for caching)
[12:47:44] <Alexey> Removed appendix describing Windows implementation
[12:47:46] <jhutz> ietf-vnc.central.org
[12:47:48] <Alexey> (as planned)
[12:48:21] <Alexey> Larry was planning to publish a separate document but changed his mind
[12:48:32] <Alexey> Sam: please add the appendix back then
[12:48:41] <Alexey> Outstanding issues:
[12:48:59] <Alexey> Validation of client referral data
[12:49:14] <Alexey> (error message from KDC is unuathenticated)
[12:49:24] <Alexey> Authorization data in cross-realm case
[12:49:33] <Alexey> NT-ENTERPRISE concept
[12:50:20] <Alexey> Validation - one realm, shared password (not smart, but usually happens)
[12:50:56] <Alexey> MITM can modify the principal
[12:51:12] <Alexey> ... assuming that the password is the same
[12:52:01] <Alexey> Old defense: each end sends the expected identity, so it can be compared
[12:52:25] <Alexey> In the new case the identity comes from network, so this doesn't work
[12:52:35] <Alexey> [missed the end[
[12:52:44] <Alexey> Validation - one realm, PKINIT
[12:52:52] <Alexey> No password
[12:53:04] <Alexey> The same MITM attack applies
[12:53:37] <Alexey> Larry corrects Ken that PKINIT case is not affected
[12:54:25] <nico> yes, it'd be nice if PA-ENC-TIMESTAMP had a reply to it
[12:54:39] <nico> that bound to the request
[12:54:46] <nico> much like PKINIT
[12:54:51] <hartmans@jis.mit.edu/owl> I think FAST solves this
[12:54:53] <Alexey> Larry confirmed that check sum includes the client name
[12:55:01] <nico> IIRC we made sure we solved this problem with PKIIT
[12:55:03] <Alexey> Validation - multiple realms case
[12:55:18] <nico> it isn't an accident that this problem doesn't exist there
[12:55:59] <Alexey> Need to protect KRB-ERROR
[12:56:38] <Alexey> (An attacker can compromise the second realm and return wrong information)
[12:56:43] <nico> could we shove cleartext integ prot for KRB-ERROR into e-data?
[12:57:01] <Alexey> Ken doesn't have a good idea about fixing this
[12:57:12] <jhutz> unfortunately, even one client (even mine) seems to make drawing much slower. I'll have to see if there is a way to make the slowness only affect remote clients and not interfere with the local ones.
[12:57:22] <nico> client-side policy is not really a good answer -- the whole point of this is to not need that
[12:57:49] <nico> how does one tunnel vnc through a filrewall?
[12:58:28] <nico> scroll up?
[12:58:32] <jhutz> I don't know. Except that it's TCP
[12:58:43] <Alexey> Ken replies to Nico: no better solution than client side policy. Agrees that this is bad solution
[12:59:29] <nico> in the x-realm case we do
[12:59:35] <nico> have a key
[12:59:47] <jhutz> no, in the client cross-realm referral case we do not.
[12:59:48] <nico> we have a key in all cases where referrals could work safely
[12:59:48] <Alexey> In reply to "could we shove cleartext integ prot for KRB-ERROR into e-data?" (Sam and others): we don't have a key
[13:00:30] <nico> summarize?
[13:00:52] <jhutz> cross-realm client referrals are where your AS tells you go talk to another realm.
[13:01:01] <jhutz> because it's not really your AS
[13:01:18] <nico> in the TGS case though we have a key
[13:01:33] <nico> in the AS case I'd say: don't follow it
[13:01:39] <jhutz> but we're talking about client name canonicalization.
[13:01:40] <nico> unless you have PKINIT
[13:01:43] <Alexey> Tom Yu: a client got redirected to a compromised realm
[13:01:56] <nico> there's two parts to referrals
[13:02:00] <jhutz> we're talking about something that only happens when you're getting initial tickets
[13:02:03] <nico> one's for cname canon
[13:02:08] <nico> the other is for sname canon
[13:02:15] <jhutz> yes, and we're talking about client names
[13:02:18] <nico> ah, then I was confused
[13:02:41] <nico> well, using PKINIT seems like a good mitigation :)
[13:03:10] <Alexey> Tom: is this worse than the current situation
[13:04:41] <Alexey> Sam: a simple solution - ask the user
[13:05:33] <Alexey> Larry: can be ugly, if name is mapped (e.g. in an enterprise)
[13:05:54] <Alexey> jhutz: user will say yes to every dialog problem
[13:09:01] <Alexey> Ken: use client side policy (not great)
[13:09:26] <Alexey> jhutz: if we had a way to protect the negotiation, the problem would go away
[13:09:40] <jhutz> note other people said that before I did
[13:10:48] <Alexey> AD-KDC-Issued description doesn't give any hints on how cross-realm cases should be addressed
[13:10:57] <Alexey> text is unclear
[13:16:12] <Alexey> Ken: should we just not describe complicated cross-realm cases in this document?
[13:17:51] <Alexey> Sam: we should handle aliases in the client's realm
[13:18:10] <Alexey> NT-ENTERPRISE names - how is it interpreted?
[13:18:24] <Alexey> Does realm matter? Or is it ignored?
[13:20:33] <Alexey> Sam: the realm is the name of the routing authority to resolve this name
[13:21:34] <nico> I wish RFC4120 said more about enterprise names
[13:23:01] <Alexey> Other client in c14n/referral
[13:23:31] <Alexey> Any reason to disallow canonicalization for other name types?
[13:25:38] <Alexey> Ken: prefers not to special case NT-ENTERPRISE names, if possible
[13:26:21] <mrex> there is a type of name implemented in Microsoft's Kerberos that is a royal PITA, because it is extremely difficult to find the user account in the Active Directory for the Kerberos Principal name that is in the ticket
[13:26:52] <Alexey> Leif: canonicalization also applies to Anonymous
[13:27:12] <mrex> If that is an incarnation of NT-ENTERPRISE, then I would love to see it buried far and deep
[13:27:41] <Alexey> Other ToDo:
[13:28:05] <Alexey> Add more examples: u2u, cross realm (?)
[13:28:09] <jhutz> is simon in the room?
[13:30:21] <Alexey> jhutz is disappointed that we are not behind on our meeting agenda
[13:30:34] <Alexey> jhutz: Kerberos 5.3
[13:31:22] <Alexey> "Chicago proposal":
[13:31:32] <Alexey> Negotiation via FAST/STARTTLS
[13:31:39] <tlyu@jis.mit.edu> hm, "SLNT"?
[13:31:50] <Alexey> FAST/STARTTLS for Auth Cleartext
[13:31:58] <Alexey> Simplified protocol messages
[13:32:27] <Alexey> Ticket Extensions Enctype Hack
[13:32:51] <Alexey> Is FAST REQUIRED/RECOMMENDED/?
[13:32:58] <Alexey> Same questions for STARTTLS
[13:33:56] --- Ken has joined
[13:33:59] <nico> he wasn't at SASL
[13:34:59] <nico> there's PKINIT in FAST
[13:35:02] <Alexey> Love channeling Simon: Simon wants I18N to be fixed
[13:35:39] <nico> yes, but which must be implemented
[13:36:26] <Alexey> Simon is not going to do PKINIT (which is in FAST)
[13:36:54] <nico> PKINIT is already on the Standards-Track
[13:37:23] <nico> StartTLS should have been discussed as a Standards-Track solution much earlier
[13:37:59] <nico> I don't mind using either StartTLS or FAST for 5.3 negotiation
[13:37:59] --- tim.polk has joined
[13:38:51] <nico> most implementors could probably implement both "eventually"
[13:40:05] <nico> what is "this thing"?
[13:40:56] <Alexey> jhutz tries to summarize
[13:41:31] <Alexey> The decision about FAST versa STARTTLS doesn't have to be tied to the decision about Chicago proposal
[13:41:34] --- guenther has left
[13:41:50] <nico> we should decide to use both things and decide which is REQUIRED to implement later
[13:41:58] <nico> but we can't avoid that issue eventually
[13:42:15] <nico> fine
[13:42:17] <nico> alternatively
[13:42:29] <nico> introduce third PA-DATA for negotiation
[13:42:43] <nico> and require that FAST and StartTLS both protect this
[13:42:48] <nico> channel me
[13:43:14] <nico> we can decouple development of FAST, StartTLS and 5.3
[13:44:09] <nico> how is it more work?
[13:44:28] <nico> the new PA-DATA is a constant
[13:44:56] <nico> I didn't follow Sam's comment
[13:45:26] <nico> no
[13:45:30] <nico> one round trip
[13:45:35] <nico> client sends both
[13:45:50] <nico> FAST and the new PA-DATA either inside or outside FAST, provided
[13:45:55] <nico> my cell phone
[13:45:59] <nico> not at my office
[13:46:01] <mrex> The STARTTLS has a large footprint (codewise) because it requires a full seperate protocol stack to be included (I'm already shipping that code on the same box is a very poor excuse in my view)
[13:46:12] <nico> provided that FAST protects the new PA-DATA
[13:48:20] <tlyu@jis.mit.edu> how many geeks does it take to improvise a phone patch?
[13:49:33] <jhutz> three, apparently
[13:52:18] <jhutz> hold on, nico
[13:53:12] <Alexey> ...Phone conversion between Sam and Nico on decoupling...
[13:56:17] <nico> I have to go in three minutes
[13:57:05] <Alexey> Leif: if we can anticipate a third way, then the argument for decoupling is much stronger
[13:58:28] <Alexey> Sam would like to make pieces as independent as possible, and as small as possible, so that stuff can actually be deployed
[13:59:31] <nico> we care about I18N
[14:00:40] <nico> and about improved pre-auth
[14:00:46] <jhutz> who is "we", nico? Sun?
[14:00:51] <nico> Shawn can confirm or deny
[14:00:52] <nico> Sun
[14:01:01] <semery@jis.mit.edu> Confirm
[14:01:22] <nico> and Sun is a Kerberos Consortium member
[14:01:35] <hbhotz> JPL would like I18N, but we have no problem that requires it.
[14:01:37] <nico> so if Sam needed to hear that we care about both of those items, then he's now heard it
[14:02:03] <semery@jis.mit.edu> DoS on clear text is also a concern.
[14:02:07] <nico> relative priorities, thats harder to say
[14:02:16] <nico> and I defer to Shawn on priorities
[14:03:05] <Alexey> Tim: you need to decide on order and available resources.
[14:03:43] <nico> we've not touched StartTLS and channel bindings yet
[14:03:51] <nico> did Simon respond to that?
[14:06:26] <Alexey> Sam: start work on message format
[14:08:50] <hartmans@jis.mit.edu/owl> I will naturally follow up with Sun on their comments about priorities.
[14:09:17] <Alexey> jhutz: Milestones
[14:11:33] <Alexey> Hash agility for PKINIT - needs test vectors
[14:11:39] <Alexey> Move to March 2008
[14:12:38] <Alexey> February 2008 (WGLC) for preauth framework
[14:13:04] <Alexey> Leave OTP milestone as is (already late)
[14:13:19] <Alexey> hardware preauth - new editor?
[14:13:42] <Alexey> data model - leave as December 2007
[14:14:46] <Alexey> WGLC on Referrals - move to April
[14:15:07] --- semery@jis.mit.edu has left: Disconnected
[14:16:03] <Alexey> LDAP schema - push to August 2008
[14:18:47] <Alexey> Straw poll: derived principal name authorization draft - how many read?
[14:18:52] <Alexey> 2 (chairs)
[14:19:19] <Alexey> how many people read cross-realm problem statement?
[14:19:21] <Alexey> 5 hands
[14:20:02] <Alexey> how many people know about X.509 problems in u2u?
[14:20:05] <Alexey> About 6
[14:20:12] <Alexey> Sam: cries now
[14:20:38] <Alexey> s/now/no (regarding discussing this in the meeting)
[14:21:10] <hbhotz> me
[14:21:31] <Alexey> Leif: I will publish KAML problem statement, please review
[14:21:52] <hbhotz> Should kaml first do a framework for authz data?
[14:23:37] <Alexey> Shawn talks about "derived principal name authorization draft" draft
[14:24:33] <Alexey> Delayed/Long Running Processes, how to authenticate them
[14:25:09] <Alexey> Problems: extend the lifetime of TGT to infinity is not a good idea
[14:26:28] <Alexey> Proposal: create new multi-component principals per service and host
[14:26:53] <Alexey> Advantages: each will have a separate key
[14:27:05] <Alexey> Also useful for auditing (as each name is unique)
[14:27:14] <Alexey> Authorization becomes easy
[14:27:52] <Alexey> Disadvantages:
[14:28:30] <Alexey> the implied authorization gives the multi-component principal all right as that user
[14:28:48] --- lha has left
[14:28:58] <Alexey> so it is bad if compromised
[14:29:14] <Alexey> Another proposal: post dates ticket - already standardized
[14:29:43] <Alexey> Sam: authorization needs to be in the application protocol, not in KDC
[14:30:32] <Alexey> jhutz: regarding proposal 1: remove implicit authorization and the disadvantage goes away
[14:31:59] --- tim.polk has left
[14:32:12] <Alexey> Tom Yu: create a ticket with short lifetime, but long renewable time?
[14:32:25] <Alexey> (forwardable ticket)
[14:32:36] <Alexey> Sam/Shawn: too much protocol interaction
[14:33:54] <Alexey> We are done
[14:33:57] --- finn- has left
[14:34:29] --- Alexey has left
[14:34:40] --- tlyu@jis.mit.edu has left
[14:35:15] --- jhutz has left
[14:35:32] --- mrex has left
[14:35:37] --- ietf-meeting has left: Disconnected
[14:36:02] --- Ken has left
[14:40:52] --- he has left
[14:41:08] --- hbhotz has left
[14:46:27] --- sommer@jabber.cc has left
[14:49:21] --- ShoichiSakane has left
[14:55:33] --- nico has left