Replay cacheing is a pain
Solutions: Fast replay caching with cutoff time, use of adaptive bloom algorithm, or memory cache.
Another Solution: Implicit 3rd leg.
Sam Hartman: if you use freshness in message or in the channel binding then the cache is not necessary.
Nicolas Williams: never mind channel binding here.
Nicolas: Yes, we need a flag to do two things: 1) to tell the server we're doing this, 2) to ensure that the AP-REQ is not accepted in some other context if cut-n-pasted.
Sam: Why we care about the cut-n-paste?
Nicolas: because we might not have a channel, think of rsh.
Greg Hudson: If you don't insert the authenticator into the replay cache, it could be replayed to a different protocol which doesn't have the nice properties.
Greg: Even if the other protocol implementation uses a replay cache.
Nicolas: You might remember this issue from SSHv2 + GSS...
Another Solution: Explicit 3rd leg.
Sam: This is sounding very kbr specific – comments.
Nicolas: Yes, this is more for Kerberos than for KITTEN.
Nicolas: There's some GSS impact; new req_flag and all.
Nicolas: The fast replay cache stuff is relevant to all sorts of things.
Sam: I agree that the gss flags and stuff are general.
Nicolas: I really want the mech to support u2u.
Replay caching for clusters is difficult and hard to get right for file systems.
Consensus questions:
Which solution of the three should be used?
Sam: what if we want multiple solutions?
Sam: Implied leg required - explicit would be nice for people who implement.
Nicolas: yes, I agree, implied 3rd is best, and we ought to always make app protocols make implied 3rd leg suffice.
Sam: no interop problems because two different people are using different solutions.
Nicolas: the initiator chooses which, if we spec both.
Greg: I'm a little confused on how you negotiate explicit third-leg given that authenticators using it have to be unacceptable to old software.
Nicolas: AP-REP extension.
Sam: So you'd rather not do explicit third? I can live with that too.
Sam: to greg - new OID.
Nicolas: no new OID!!! Not that I don't like it, we don't need it!!
Nicolas: this works without a new OID.
Tom Yu: maybe need more study?
Greg: I'm fine with going in the implied third leg direction, so the question about explicit third leg may be moot.
Sam: is there anyone who does not want to do implicit third leg?
Sam: If never get beyond that point should be fine.
Nico: good point.
Sam: how else do you negotiate explicit third vs old style?
Nicolas: also, we still need fast rcache for any apps that use PROT_READY -- or we could deprecate PROT_READY.
Nicolas: AP-REQ has flag requesting explicit 3rd leg, old server sends old AP-REP, new server sends *new* AP-REP.
Sam: deprecate replay_det for prot_ready.
Nicolas: good point.
Sam: ...or just not set replay_det for prot_ready.
Nico: you can't not set replay_det for prot_ready -- this is on the peer side.
Sam: you can fail to set the flag for whether the service is available.
Sam: I.E. we can say that 4121 mechanisms must not set replay detection as an available service until context is fully established.
Nicolas: the PROT_READY token will not be processed until the context is complete.
Shawn: Implied third leg should be a solution - show hands.
Greg: +1 on implied third leg.
Nico: +1 on implied 3rd leg.
Nico: (this might means I need not finish my fast rcache code!
Shawn: Who does not think that implied 3rd leg is a solution?
Shawn: CONCENSUS - Yes it is a solution.
Shawn: Who would like the explicit 3rd leg as a solution?
Nico: I'd work on it, if we agreed that we need it, but I could live with implied 3rd leg only.
Greg: No opinion one way or another for explicit third.
Tom: Who thinks we should not do the explicit 3rd leg option?
No votes either way.
Nicolas: alright, so no explicit 3rd leg then.
Nicolas: question: are there GSS mechs for which we might want it?
Nicolas: do we want to spec the req_flag for it.
Sam: Is there any harm in delaying the flag until somebody explicitly says they want it?
Nicolas: No harm.
Nicolas: Sam had suggested that for state cookies we might want a generic utility function, to make app devs' lives easier, and I agree.
Sam: would probably be done in the IETF.
Sam: Have sym key - take exported context - encrypt it - associated data and make it a utilty function in the glue layer so that nobody needs to repeat creating the code.
Nicolas: Suggested consensus questions: do we want to do partially established sec context export? and if so do we want to do encrypted state cookie utilities (export-and-encrypt, decrypt-and-import).
Greg: So you have to pass a key to this utility function?
Nicolas: Probably not, no -- either the caller has access to the key, or not, with the key stored 0600 somewhere where if the app re-starts you could find it.
Sam: you may need to have mechanism attributes - i.e. re-use of counters for counter mode ciphers.
Sam: I think it is the case that you can only hurt yourself.
Nicolas: no re-use counters -- no replay detection with this unless we slap on a replay cache -- we want that as a flag on the export-and-encrypt and an output flag on decrypt-and-import.
Greg: I'm thinking about cases where a different KDC imports the context than exported it.
Nicolas: Yes, same answer.
Sam: An attacker outside of the conversation would not have and advantage - but we need to do a check on this to make sure it is true.
Sam: Define a new mechismism attribute "replay my context" and query for it before generating the cookie.
Sam: glue - just have an export, import and pass some flagus such as replay question.
Sam: yes store key in the glue - maybe pass in a key name.
Nicolas: we probably want a cluster flag too!
Sam: Hope we don't need a replay cache for first version - would need to look at the cache being a cluster.
Nicolas: so we can return an error if there's no cluster rcache support)
Nicolas: So don't use counter mode here!!
Greg: I'm still confused about this encryption key. Does the mechglue make it up? If I were using this on a KDC, I'd want to use a key shared between the KDCs.
Nicolas: The admin does, and puts it where the mechglue expects it, or else the mechglue gens it and the admin syncs it on clusters.
Sam: I am fine if you kill yourself - just not others.
Sam: Yes - use a shared key between KDCs.
Nicolas: Yes, the cookie wants a key _name_. Not true, GSS pre-auth!
Nicolas: I'm saying this key sharing issue is an implementation issue, not one we should care about.
Tom: do we want to standardize the context - what about versioning if it is mech specific?
Sam: leave up to mech.
Shawn: Who thinks this is an issue that they want to solve?
Nicolas: I do! I think we should at least allow gss_export/import_sec_context() to do partial sec contexts.
Shawn: Should we create a utility function to export partial security contexts?
- 7 rose their hand -
Nicolas: I think we should spec a utility function, because we need to make this easy and safe to use, else it will be misused, and that would be bad.
Sam: I think the implementation issues are important for this API, sort of.
Sam: Especially if you want an abstraction between the mechglue and the kdc.
Sam: Which I think you want because the kdc is massively non-unique.
Sam: For example a distributed RADIUS server would want exactly the same thing probably.
Nicolas: Yes, but we *can* solve them and they are not relevant to KITTEN itself.
Sam: I think they do matter for the interface.
Nicolas: yes, so maybe we don't want the mechglue doing this, but the mech. provider (because mech_krb5 could know to look in the keytab/KDB for the key).
Nicolas: I think we don't want anything more than a key name in the API.
Sam: I think I've been convinced that Greg is right and you need to be able to pass in a key.
Nicolas: Configuration is not a problem, also, this could be yet another use case for the PGSS discussion.
CONCENSUS - Get a design team together to hash out the interface and define the token format.
Shawn: Call for volunteers?
Sam, Nicolas, and Greg volunteers.
Greg: This is sort of interesting because GSSAPI doesn't currently traffic in keys.
Sam: Agreed.
Nicolas: Yes, but I'd just use a name, not a key.
Sam: I'd like to convince myself that Nico is right and that all you want is a key name.
Nicolas: I don't mind an option to specify the key, but I want it to be optional.
Sam: Definitely optional.
Nicolas: Good, so we agree.
Nicolas: C bindings issues, not abstract API issues.
Nicolas: Two apps in same process.
Nicolas: Not flag, return value.
Possible Solutions:
Tom: change header file - change the C type in the header file.
Nicolas: Change minor_status to an opaque type.
Sam: I am not an app developer - I do mechs - I think there is value even if the mechs change and the apps don't - if you can improve the SPI between the glue and the mechs then there is value even if you don't have it for the apps until later.
Nicolas: If the app gets no value, then what's the point?
Sam: Need all mechs to change however.
Greg: Perhaps applications aren't motivated to change, but library users are (for better isolation between themselves and apps).
Sam: for memory allocation issue if glue/mech is cleaned up then easier to clean leaks?
Nicolas: basically, a v3 SPI would allow the mechglue to tell the providers what allocator to use, however I also had in mind crypto HW where the memory must be allocated from a driver, not a normal allocator.
Nicolas: I wonder what the latency is, it seems like "a lot".
Greg: Can't a mechglue, today, just copy the mech's result buffer so it knows all caller-visible buffers are allocated by the mechglue?
Nicolas: Memory copies kill performance.
Greg: I feel like we already kill performance past that point, but let'smove on.
Nicolas: Sure, not for SSHv2 w/ GSS, but for NFSv4?!
Sam: If we aqre going to do work - please have somebody say there is a problem that I have today.
Sam: Want current use cases of problems.
Sam: As a mech implementer the memory manage problems are killing me.
Sam: Other use case that is problematic is needing more extensibility for acquire creds.
Sam: Any other app developers want to give problems?
Nicolas: I could use GSS initial cred acquisition, so, yes.
Tom (self): Krb consortium has heard from sponsors - might have programs in a single process to handle different sets of configuration.
Tom: Can only do this by changing env variables or files in the file system - in a single process this would need a new context handle to pass in - would be useful.
Nicolas: In addition, I have other use cases, some which I may need to implement later this year, in particular dealing with multiple providers for the same mechanism.
Sam: are you willing to re-write code?
Tom: yes - if high confidence a good solution not horrible to implement.
Nicolas: I will likely write a GSS proxy library, and I'd like the mechglue to be able to use that and a regular provider for the same mechs.
Greg: I think I might be willing to write mechglue and krb5 mech code for gss3 if there were a standard behind it.
Nicolas: Most of the mechglue can be generated from a gss function description model and a compiler for it.
Sam: stylistic question - lots of types and functions or not - prefer lots of apis with with small parameters, use an object to pass in options.
Nicolas: yes, I do dislike that pattern.
Sam: Easier to decide what to do if we have a style to choose from now.
Sam: If they don't use that design pattern then far from solution.
Sam: If gss-api v3 rewrite - then will have a sam/nico argument about how it should be done.
Nicolas: note that we could look at other successful APIs for ideas.
Nicolas: Also, we could ask various people who've voiced opinions in the past in this area.
Nicolas: I abhor this museum of v2u1 APIs that we're building
Sam: Need to have the style decision before knowing which option to support.
Greg: I am not able to connect the dots between options objects and not needing a gss3.
Sam: we might have almost enough option objects not to need a gss3.
Sam: need to propose some extensions that are not in the gss3 timeframe and need to know what style to use for that.
Sam: don't know if the right people and enough thought at the point on the decision.
Tom: Who thinks that the memory management problem needs fixed?
6 raises hand
0 don't that memory management is an issue.
Sam: no, you just need copies, cannot currently do it on windows w/o this.
Nicolas: yeah, we're already requiring one mem allocator.
Sam: I think I could agree that we should not do ad-hoc things.