[12:48:44] --- frank has joined
[12:49:08] --- frank has left
[13:50:29] --- guenther has joined
[13:53:14] --- hartmans@jis.mit.edu/owl has joined
[13:53:22] --- ietf-meeting has joined
[13:53:52] --- nico has joined
[13:54:09] --- ietf-meeting has left: Disconnected
[13:55:46] --- ietf-meeting has joined
[13:59:10] --- raeburn has joined
[14:01:17] --- jhutz has joined
[14:01:25] <jhutz> welcome to kitten
[14:01:29] <jhutz> can everyone hear the audio?
[14:01:55] --- mrex has joined
[14:02:45] <jhutz> I'll try to take my notes here; someone (nico?) should back me up if I miss something.
[14:03:02] <jhutz> any agenda bashing?
[14:04:01] <jhutz> materials for this meeting are available online at https://datatracker.ietf.org/meeting/69/materials.html
[14:04:34] <jhutz> issues with domain-based names (draft-ietf-kitten-gssapi-domain-based-names-03.txt)
[14:04:45] <jhutz> Several DISCUSS comments in iesg review...
[14:04:54] <jhutz> Actually, and some comments.
[14:05:14] <jhutz> comments - express syntax in ABNF?
[14:05:53] <jhutz> alexei: might be better to wait on that until i18n discussion
[14:06:15] <jhutz> clarify - "service" is a GSSAPI service name, not a well-known port name
[14:06:53] <jhutz> some examples use incorrect example domain names; they need to be corrected
[14:06:55] <mrex> so the service names are more precisely "protocol names", distinguishing protocols rather than (specific) instances of a service?
[14:07:01] <jhutz> major issue - i18n
[14:07:24] <jhutz> No. Service names here are GSSAPI/Kerberos/SASL service names, as registered in IANA
[14:07:46] <jhutz> (there is a registry with that name)
[14:08:02] <mrex> while this is normally not an issue for hostbased-service names, because there usually is a well-known port associated with it and there is usually one listener per port
[14:08:02] <jhutz> Query: Can remote people hear us over the hammering?
[14:08:21] --- tlyu has joined
[14:08:49] <mrex> I started wondering what service was supposed to mean for domain-based service name, where I could easily conceive more than one instance of a particular service per domain (not necessarily per host)
[14:08:59] <jhutz> no; hostbased service names also use "GSSAPI/Kerberos/SASL service names", not names of well-known ports
[14:09:35] <jhutz> Nico: that in practice there is often a well-known port name is irrelevant
[14:09:40] <guenther> is it also because there's no implied binding to the port number that's associated with a WKS?
[14:09:55] <jhutz> hartmans: I think the i18n issue can be decomposed into a couple of different sub-questions
[14:10:28] <jhutz> nico: we have to specify what is a domain-name slot and what isn't.
[14:10:47] <jhutz> : we basically have to say that both the "domain" and "hostname" parts need to be domain-name slots
[14:11:13] <jhutz> hartmans: (1) what does a particular mech use on the wire? (2) what do I pass in the API?
[14:11:48] <jhutz> sam: Once you answer (2) for GSS_Import_name_UTF8, the answer is obvious for other api's.
[14:13:41] --- alexeymelnikov has joined
[14:13:55] <jhutz> nico: ToUnicode is the identity function when input is unicode, and ToACE [toASCII?] is identity when the input is all ASCII, not ACE, and appropriate for use in DNS labels.
[14:14:05] <jhutz> sam: clarification: is ToACE identitiy on ACE?
[14:14:09] <jhutz> nico: yes
[14:14:15] --- finn- has joined
[14:14:25] <jhutz> nico: So, app can pass in either; the mech must call ToUnicode or ToACE as appropriate.
[14:14:33] <jhutz> ... and doesn't care what the input is
[14:14:53] <mrex> the output of gss_display_name() is purely for human consumption
[14:15:13] <jhutz> sam: I think this is a case where "be liberal in what you accept" makes a lot of sense; we should say implementations must accept either a-labels or u-labels
[14:15:36] <jhutz> nico: mrex, so we can make gss_display_name emit unicode, not ACE
[14:16:33] <jhutz> nico: So, when importing names, mechanism must call ToASCII or ToUnicode as appropriate; cannot pass it along unmodified unless the next API has the same propery. For display names, we use UTF-8.
[14:16:40] <mrex> common sense sort-of dictates that the output of gss_display_name() (which is accompanied by a nametype OID) is parsable/acceptable to gss_import_name() of the very same implementation (not necessarily for the peers implementation)
[14:17:11] <guenther> jhutz: for the C API, the API accepts latin1
[14:17:22] <nico> mrex: what we just described has that property
[14:17:50] <guenther> jhutz: however, no such names are permitted in hostnanes
[14:18:07] <jhutz> jhutz: So, I think the right answer for the old interface is to expect and specify that IDNA names always be used.
[14:18:36] <jhutz> hartmans: All we can say is callers must pass in ASCII or ACE to gss_import_name.
[14:19:32] <jhutz> hartmans: I think both the implementation strategies of return ACE or return Latin-1 for display names are reasonable, and so the most we can say is implementations SHOULD return ACE, but not MUST.
[14:20:14] <jhutz> Nico: Hostnames, Domain names are domain name slots
[14:20:22] <jhutz> nico: service names are ASCII-only, from the registry
[14:20:40] <mrex> ignoring the issue for the "legacy" (latin-1-specified) does not seem practical for me. Expect that there will be a lot of applications continue to call the non-i18n versions of gss_import_name() and gss_display_name()
[14:20:41] <jhutz> nico: non-internationalized interfaces take ASCII or ACE; SHOULD output ACE
[14:21:00] <jhutz> nico: internationalized interfaces MUST accept UTF-8 or ACE; should output UTF-8
[14:21:49] <jhutz> Nico: We're not ignoring legacy latin1; implementations that currently allow it can do so.
[14:22:11] <jhutz> jhutz: Note that we are talking about domain-based service names specifically.
[14:22:21] <mrex> the situation will be difficult for SPNEGO and pluggable-mechanisms faced with a mix of i18n-supporting and non-i18n-supporting mechs
[14:22:50] <jhutz> hartmans: We should tell the Kerberos WG that we need an answer now on what they're going to do wrt hostnames.
[14:23:15] <jhutz> [OK. My comments to jabber in brackets; stuff not in brackets is what happened in the room]
[14:23:24] <jhutz> nico: ....
[14:23:37] <jhutz> hartmans: The issues is, 4120 has idna-unaware domain-name slots
[14:24:06] <nico> mrex: having an implementation of SPNEGO I don't agree that this causes a problem for it
[14:24:32] <jhutz> jhutz: I don't believe 4120 contains domain-name slots
[14:24:37] <jhutz> sam: host-based principal names
[14:25:25] <mrex> the problem arises from the fact that the latin-1 restriction in the C-bindings was hardly followed, most used just-use-8 similar to MIT Kerberos
[14:26:16] <tlyu> consider a username of "host" having instances with different privilege levels....
[14:27:33] <jhutz> [I don't think it's as big a problem as you thnk]
[14:27:42] <mrex> still I'm wondering about the concept of seperate independent instances of a service within a domain
[14:27:45] <mrex> yup
[14:27:47] <jhutz> mrex, do you want us to read and discuss those comments in the room
[14:28:10] --- ja has joined
[14:28:41] <jhutz> [but we are talking about domain-based service names, _not_ the general case.]
[14:30:24] <mrex> Punycode is valid ascii, isn't it. For legacy gssapi implementations I would have reused the same hostname for DNS and for hostbased service names
[14:31:00] <hartmans@jis.mit.edu/owl> Martin I agree with you and think Jeff is wrong about there not being ace hostnames
[14:32:10] <jhutz> [I didn't say there weren't ACE hostnames. I said, or tried to say, there probably aren't existing things using _domain-based_ service names with _non-ASCII_ characters. ACE hostnames don't count, and neither do non-domain-based non-ASCII service names].
[14:32:34] --- Melinda has joined
[14:32:41] <nico> further, doesn't Windows support internationalied domainnames in just-send-unnormalized-utf-8 form? (i.e., non-compliant)
[14:33:52] <jhutz> [Note that if we say that domain-based service names expect IDNA names from the legacy interfaces, that is actually compatible with the behavior I would expect from legacy applications. We can certainly say that people who start using domain-based service names with legacy applications (not sure why you'd do that) simply need to write them with IDNA as needed].
[14:33:58] <jhutz> On to channel bindings...
[14:34:11] <jhutz> Except now I am lost.
[14:34:27] <jhutz> draft-ietf-kitten-gssapi-channel-bindings-02...
[14:34:53] <jhutz> needs to be aligned to and depend on draft-williams-on-channel-binding
[14:35:19] <jhutz> .. needs to be aligned with updates to TLS channel bindings I-D's
[14:35:24] <jhutz> Otherwise pretty much ready to do
[14:35:44] <jhutz> draft-ietf-kitten-stackable-pseudo-mechs-02
[14:35:47] <mrex> During the gssapi-over-tls discussions I significantly developed my personal mental model about channel bindings, their purpose and characteristics. I hope to find the time to review and comment on the existing documents
[14:36:10] <jhutz> Nico: still needs lots of work. needs a good destriction of how you figure out what the possible composite mechs are; we know how to do that, but it needs text.
[14:36:17] <jhutz> shawn: should it be put on hold until....
[14:36:22] <jhutz> nico: ... until a consumer comes along.
[14:36:51] <jhutz> [mrex, good; you should comment]
[14:37:31] <jhutz> nico: pseudo-mechs tend to make up for app protocol shortcomings, but at least for internet app protocols, it tends to be just as easy to just fix the app protocol rather than design a pseudo-mech
[14:37:51] <jhutz> Nico: This document could end up in a hold for a while.
[14:38:03] <jhutz> Nico: It will affect milestones; maybe Sam will object
[14:38:08] <jhutz> (hartmans shakes head)
[14:38:20] <jhutz> draft-ietf-kitten-extended-mech-inquiry-02
[14:38:36] <jhutz> Nico: Pretty close; needs intro, sec cons text.
[14:39:02] <jhutz> Nico: If we drop stackable pseudo-mechs, we drop a bunch of attributes, but this is still useful.
[14:39:10] <jhutz> draft-ietf-kitten-gssapi-naming-exts-02
[14:39:37] <jhutz> Nico: needs some work - how do we handle... AD-AND-OR, negative auth data, ...?
[14:39:47] <jhutz> PKIX stuff... ?
[14:40:14] <jhutz> Nico: I'm not an expert on PKIX stuff; how to map cert extensions, etc to this. Maybe time to move it out.
[14:40:28] <jhutz> hartmans: I think the PKIX stuff is important, but it's important to get it review
[14:40:49] <jhutz> hartmans: In the long term, I think this is one of the most important docs in the sec area, if it ever gets implemented.
[14:40:59] <jhutz> hartmans: May need to be prepared to split out the API form the attributes.
[14:41:20] <jhutz> hartmans: What might happen is someone needs the API urgently, can't wait for us to specify all the attributes.
[14:41:35] <jhutz> nico: So, should I split into multiple documents?
[14:41:41] <jhutz> hartmans: I wouldn't object if you did.
[14:41:46] <jhutz> nico: needs review, comments.
[14:42:11] <alexeymelnikov> Action item for chairs: find PKIX reviewers
[14:42:14] <jhutz> chairs: how many people would be willing to review?
[14:42:22] <jhutz> jhutz:me
[14:42:27] <mrex> there are two conceivable approaches: being able to query particular attributes, or being able to query all attributes (getting back an attribute value pair of whatever there is). There are several possible containers, though: Issuer, Subject, SubjectAltName, PolicyConstraints
[14:42:35] <jhutz> hartmans: might have to lock me in a room, but yes
[14:42:48] --- =JeffH has joined
[14:43:18] <jhutz> reviewers so far: larry, ken, jhutz, hartmans
[14:43:20] <mrex> Personally, I don't really like PKI(X) that much
[14:43:29] <mrex> and I don't claim to be an expert for it
[14:43:55] <jhutz> Nico: Not asking only for review of the pkix parts. Want reviewers for the API parts, other bits.
[14:44:41] --- raeburn has left: Disconnected
[14:45:25] <jhutz> draft-ietf-kitten-gssapi-extensions-iana-01
[14:45:45] <jhutz> Nico: Needs review of registration form, procedure
[14:45:58] <jhutz> Nico: needs review of initial prefix registrations and initial contents
[14:46:18] <jhutz> We need to collect registrations from existing documents.
[14:46:21] <jhutz> Help would be good.
[14:46:26] <jhutz> Yeah; I agred to help
[14:47:43] <jhutz> chairs: we need a milestone
[14:47:47] <jhutz> <discussion>
[14:47:57] <jhutz> Nico, jhutz: WGLC end of october ?
[14:48:11] <jhutz> Future work items...
[14:48:24] <jhutz> chairs: anyone to volunteer for reviewing this (iana)
[14:49:24] <jhutz> volunteers: kurt, philip
[14:49:31] --- raeburn has joined
[14:51:07] <mrex> [as you all noticed, I haven't read the gssapi-naming document. There are gssapi mechanism using X.509 certs for authentication (we use one) and there naming (extensions) is probably about accessing just about any conceivable attribute from the peers cert. Kerberos may have somewhat different issues with PKINIT or PKCROSS related naming things]
[14:51:20] <jhutz> chairs: need an editor for the C# bindings draft. any volunteers?
[14:51:46] <jhutz> [You should read the doc, then comment. It will make your comments a lot more coherent]
[14:51:52] <jhutz> [at least, in this case it will]
[14:51:53] <nico> mrex: yes, the naming doc is about accessing any inconceivable attribute of a certificate, krb5 ticket, etc...
[14:52:12] <=JeffH> chairs: who cares about C# ?
[14:52:50] <jhutz> hartmans/AD: Who currently involved in this WG is interested in implementing the C# bindings?
[14:52:55] <jhutz> <no hands>
[14:53:08] <nico> mrex: it's "naming" because the GSS-API speaks of "NAME" as an opaque object type that represents potentially complex interfaces
[14:53:19] <jhutz> hartmans/AD: I argue the bar for doing work on a language bar that no one is planning to impement is high.
[14:53:20] <nico> ^interfaces^identities^
[14:53:37] <jhutz> Nico: I say drop it
[14:53:46] <jhutz> hartmans: check with the list first, of course
[14:54:26] <jhutz> leifj: I think we need to talk about exporting partially-established contexts
[14:54:33] <jhutz> chairs: come back at the end of the slide
[14:54:50] <jhutz> chairs: We need an editor for the C-bindings draft (v2u1)
[14:55:04] <mrex> [I think I read it quite a while back and commented on kitten mailing list, but it was sufficiently long ago and to far off my personal radar that I don't really remember the details -- sorry for the unfocused comment]
[14:56:08] <mrex> how many open source c# are there (as potential consumers in the open source space)?
[14:56:15] <mrex> +apps
[14:56:25] <jhutz> jaltman says he is no longer editing the c-bindings update, and does not have partially-complete text to hand off
[14:56:58] <jhutz> [I haven't a clue. But I think we agreed to drop the c# bindings doc unless someone objects]
[14:57:16] <hartmans@jis.mit.edu/owl> [Martin you definitely read the document that became RFC 4768; you provided a lot of comments and I tried to reflect them to the best of my ability.]
[14:58:27] <hartmans@jis.mit.edu/owl> That RFC describes multiple approaches. nico's naming extensions draft is something that attempts to implement one of the approaches.]
[15:01:39] <mrex> appartmentizing GSS-API v2 should be possible. Full reentrant is certainly "challenging"
[15:02:18] <nico> "appartmentizing"?
[15:02:18] --- jaltman has joined
[15:02:36] <jhutz> [No one is suggesting that it be made reentrant. The charter says the v2u1 document is supposed to discuss the thread-safety issues. Of course, we agreed not to make backward-incompatible changes]
[15:02:45] <mrex> thread-safe on independent object handles
[15:03:33] --- ja has left
[15:03:36] <tlyu> i think in practice that requires some small amount of global locking in the gss library
[15:03:36] <nico> jhutz: well, from the API p.o.v. there's no opportunity to reenter
[15:03:46] <jhutz> hartmans: what mechanisms are people talking about, that don't belong in SASL and aren't in process on the individual submission track?
[15:04:08] <nico> non-monolythic mechglue+pseudo-mechs kinda have to be reentrant
[15:04:10] <jhutz> [there are lots of opportunities to reenter when you consider multiple threads making concurrent calls]
[15:04:23] <nico> [that's not reentrance]
[15:04:31] <nico> [that's concurrence]
[15:05:06] <nico> [well, OK,that's reentrance too] considering things like strtok_r() maybe we can say
[15:05:08] <jhutz> [yeah; OK; MT-safety is not as strong a requirement as reentrancy]
[15:05:15] <mrex> some amount of global locks within the gssapi mechanism on shared information is likely necessary, but for full reentrance (instead of appartment model multi-threading), locking on gssapi objects (name,cred.context) would be required
[15:05:24] <nico> ...that's reentrantce too]
[15:05:30] --- Melinda has left
[15:05:54] <jhutz> argh; I am lost
[15:06:04] --- jaltman has left
[15:06:32] <jhutz> Nico: I kind of really want app context handles, but don't have time to edit another doc
[15:07:01] <jhutz> <nico describes what app context handles are>
[15:07:27] <jhutz> Did I miss discussion of draft-josefsson-password-auth-00, or did we punt due to simon not being here?
[15:07:38] <mrex> the motivation of abusing the minor_status was to reduce the amount of changes
[15:08:24] <jhutz> [you know, it's a little confusing to see people's names in one color on my laptop, then look up at the screen and see a different set of colors]
[15:09:09] <jhutz> Nico: The API as it is, is not inherently not thread safe. Our implementation is thread-safe, though not MT-hot
[15:09:12] <nico> mrex: right
[15:09:26] <jhutz> tlyu: Nothing says that a given minor status always maps to the same string.
[15:09:45] <jhutz> nico: but you don't know when the translation from minor_status to a string will happen, so you can never free it.
[15:10:24] <mrex> only for consciously managed applicaton contexts (which register this minor_status and release it consciously)
[15:10:33] <jhutz> tlyu: you can add a weak condition, that once you've called display_status, that number is no longer meaningful.
[15:10:46] <jhutz> jhutz: no you can't; apps may be assuming they can call display_status multiple times
[15:11:19] <nico> mrex: yes, of course, as described in the various threads
[15:11:50] <jhutz> hartmans: I was looking at simon's password auth draft. It is similar to what sasl is doing, and would be unacceptable overlap for this group to take it on. I will talk to sasl chairs; make sure it got sufficient consideration there.
[15:12:47] --- ja has joined
[15:13:32] <mrex> well, at that point it becomes difficult for applications to determine whether they're running atop v2 or v3
[15:14:07] <hartmans@jis.mit.edu/owl> Martin, true regarding determining if v3
[15:14:40] <nico> martin: we've discussed what compile / link/ run-time options to provide to detect that
[15:15:03] <mrex> (in case we publish several extensions and at one point in the future declare that a certain number of extension together with the base spec comprise v3)
[15:16:15] <jhutz> jhutz: PKU2U is hopefully ready to go to IESG soon as an individual submission. Now would be a good time to review and send comments to larry.
[15:16:57] <mrex> we use binary (not compile time) plug'n'play exclusively, and I was under the impression that Solaris and HP-UX provided some binary plug-in multi-mech as well
[15:17:04] <jhutz> leif: we need to able to export partially-complete contexsts, in order to be able to do HTTP negotiatte with more than half-round-trip mechs [right?]
[15:18:02] <mrex> exporting the entire context will be "challenging" for a mechanism spec!
[15:18:11] <jhutz> [Right; I think the point is that we define v3 to be v2 plus some set of updates, maybe deprecating some things, plus a bunch of extensions, and a means for an app to tell if the API is v3, at which point you can assume all the things v3 requires]
[15:20:04] <mrex> it may work by chance/coincidence for one particular implementation (and for a similar specific platform architecture), but I don't believe that transfering gssapi security contexts can (or should) be made in an implementation-independent fashion.
[15:21:03] <jhutz> [mrex, do you believe it would be necessary to have the tokens be interoperable across impementations, or is it good enough to have a standardized interface that emits an implementation-dependent token?]
[15:21:24] <jhutz> nico: you can assume the importing implementation will be the same, so the token can be implementation-dependent
[15:21:40] <jhutz> [personally, I agree with nico that the token format can be implementation-dependent]
[15:21:53] <mrex> even for the same implementation, i.e. MIT Kerberos running on 32-bit Intel and MIT Kerberos running on 64-bit Sparc may not be easily possible
[15:22:09] <jhutz> chairs: people interested in reviewing this document?
[15:22:25] <jhutz> [mrex, that would be up to the implementor to decide how portable his tokens are]
[15:22:46] <jhutz> volunteers to review: hartmans, ken, nico, philip, alexei
[15:22:54] <jhutz> chairs: who will volunteer to edit?
[15:23:08] <mrex> providing a guideline how it can be done if the gssapi mechanism supports it is one thing. Making a requirement for a protcol/standard what a gssapi mechanism must do is another, and I object to the latter.
[15:23:10] <jhutz> volunteers to edit: leifj
[15:23:26] <tlyu> if you need it, you'll be motivated to work on it, right?
[15:23:34] <jhutz> [So, you'd be OK with standardizing an interface to do this, but not requiring that it be supported?]
[15:23:39] <nico> mrex: presumably the implementation would have that problem with exporting fully established contexts
[15:24:03] <nico> mrex: Leif is proposing a new major status code
[15:24:06] <jhutz> leifj: Do people prefer a separate function?
[15:24:15] <guenther> tlyu: exactly, it's the fate-sharing principle applied to I-D creation
[15:24:44] <jhutz> hartmans: I think you will, because currently the OID in an export token is required to be the mech OID, and you want to be able to distinguish tokens emitted by this from tokens coming from export_context or other things.
[15:25:07] <jhutz> hartmans: ... you probably want tokens emitted by this to have an implementation-specific OID, and a requirement that if the token format changes, so does the OID
[15:25:14] <jhutz> hartmans/AD: I think this requires a charter change.
[15:25:18] <mrex> jhutz: informational document:yes, standards track document if that feature is a reqirement, probably not
[15:26:23] <mrex> jhutz: the exported security context token has NO format or framing defined
[15:27:00] <jhutz> [I think that last was for the room, not me]
[15:27:32] --- leifj has joined
[15:28:12] <jhutz> [So, this is likely to be a separate document which defines only this feature. The feature would be required if you claim to implement the document that defines it. It would not be required for things that don't claim to implement it.]
[15:28:26] <jhutz> Nico: Which track it goes into won't have any impact on whether you're required to implement it.
[15:28:33] <mrex> we dicussed exporting proto-context (security contexts that are not fully established) on the CAT mailing list back then and decided to NOT support it
[15:29:22] <mrex> Passing an exported security context around on the same host is perfectly OK, it was designed for this purpose
[15:30:05] <mrex> NOPE, no token id, no OID, Are you confusing the exported name token and the exported context token?
[15:30:10] <jhutz> [> decided to NOT support it And now we're revisiting that, and talking about a proposal to add that functionality, because today there are people who need it.]
[15:31:17] <jhutz> hartmans: or you could do it in an old function, and have it return an error as today if not supported
[15:31:21] <jhutz> nico: I prefer a separate function
[15:31:24] <jhutz> hartmans: me too
[15:31:25] <jhutz> jhutz: me too
[15:31:58] <jhutz> goals and milestones
[15:36:25] <mrex> I'm _not_ against revisiting old decisions. When GSS-API was designed, there still where strict crypto-export-regulations in place. It was not assumed that a caller of GSS-API would have crypto accessible other than as a (message protection) service by gssapi on an established security context. So the question would be: under what (crypto) key would an exported (proto)security context token would be protected if it is turned into state that the client has to present on the next round of the request--and how is that key "managed/distributed" among possible backend receipients? Public key crypto is one possible approach, but this adds a lot of crypto above GSS-API.
[15:38:44] <hartmans@jis.mit.edu/owl> I'm assuming that is an application matter. In Leif's case in a symmettric key shared among all the servers in a cluster.
[15:39:48] <leifj> right - in the use-cases for this ad-hoc key distribution is probably not a big deal an may already be in place
[15:39:49] <jhutz> [I thnk it is up to the mechanism to produce a token that it is safe to give to the client (and Leif should be sure his document REQUIRES that). As for how to share keys, well, that's going to be mechanism-specific, and we already have that problem today. For example, I'd expect krb5 mech implementations to use the krb5 service key)
[15:39:59] <jhutz> All done!
[15:40:08] <nico> indeed -- see RFC4507 for an idea of how this has been done elsewhere in the IETF
[15:40:30] <nico> it's clearly possible to deal with partially exported security contexts
[15:40:31] <mrex> one of the issues of proto-contexts: they may contain a reference to a hardware crypto token (open file handle or else) which may be needed for processing specific context level tokens, and that may not be easily transferable.
[15:40:41] <nico> there's no reason it would be OK for TLS but not for GSS
[15:40:45] --- tlyu has left: Disconnected
[15:40:53] <alexeymelnikov> I have an action item: suggest the updated milestones
[15:40:59] <nico> the only issues are API issues, and we've dealt with those today
[15:41:09] <nico> martin: even then!
[15:41:15] <leifj> mrex: you're right, it won't be a solution which works everywhere
[15:41:24] <hartmans@jis.mit.edu/owl> No, 4507 is not partial contexts. I was assuming that the GSS-API would not give a safe token.
[15:41:45] <nico> the worst case is hw token egenerated and non-extractable keys
[15:41:58] <nico> and even then you can do it (encrypt in all cluster members private keys)
[15:42:22] <nico> though it may be painful enough that you don't want to support that case
[15:42:39] <nico> but that's why we'll have new functions that will be allowed to return an error
[15:43:39] <mrex> there is also the issue that for some output objects from gssapi context establishment calls it is not defined whether they are created during the first iteration call or during a succesor iteration call. So how does the caller deal with that?
[15:45:18] <mrex> do you want to put up a new requirement that the caller will have to (newly) create all output objects on all iteration calls (like src_name)
[15:46:06] <mrex> and what about delegated_cred. And what about servers that use the delegated cred to access some other resource?
[15:46:07] <hartmans@jis.mit.edu/owl> I don't understand why that requirement is necessary? I think that exporting the context will destroy any object that is created but I don't see any problem beyond that.
[15:46:12] <jhutz> sam, if it doesn't give a safe tokoen, then it needs to say _that_ so apps know they have to protect it.
[15:47:08] <jhutz> GONE
[15:47:10] --- jhutz has left
[15:47:31] --- ja has left
[15:48:11] --- ietf-meeting has left: Disconnected
[15:48:15] --- leifj has left
[15:49:11] <mrex> There already were complaints about not being able to extract a delegated credential from a exported&imported security context. The semantics are more difficult if the security context isn't even fully established
[15:50:42] --- raeburn has left: Logged out
[15:51:26] --- finn- has left
[15:58:16] --- guenther has left
[16:00:20] --- alexeymelnikov has left
[16:00:21] --- nico has left: Disconnected
[16:01:05] --- finn- has joined
[16:01:25] --- finn- has left
[16:02:04] --- =JeffH has left: Logged out
[17:25:51] --- alexeymelnikov has joined
[18:04:01] --- alexeymelnikov has left
[18:55:55] --- alexeymelnikov has joined
[19:18:37] --- alexeymelnikov has left