Friday, November 8, 2013< ^ >
stpeter has set the subject to: KITTEN WG |
Room Configuration
Room Occupants

[00:00:10] <nico> mrex-ietf: it can be fine for DTLS; the problem here is long-term and ticket session key keys in Kerberos
[00:00:40] <Rhys> still in line
[00:00:49] <> Thanks for sticking with us, Rhys.
[00:00:53] <Rhys> :)
[00:01:19] <mrex-ietf> DTLS is broken because it says "SHOULD ignore MAC errors"
[00:02:28] <> I need to start saying "enctypes 17/18" instead of just "AES"
[00:03:27] <mrex-ietf> microsoft is an "installed base too large to ignore"
[00:04:36] <> mic: I just want to know if there are known concrete examples, or if
the issue remains purely theoretical.
[00:05:20] <nico> mic: I'm utterly uncomfortable with that for long-term keys
[00:05:26] <nico> and for Ticket session keys
[00:05:42] <ghudson> I think Sam is looking for math to back up your discomfort.
[00:05:45] <nico> clients either can't or don't keep state!
[00:06:11] <nico> ghudson: for long-term keys we'd have to pick IVs randomly
[00:06:25] <nico> many clients won't have great entropy available
[00:06:40] <Tom Yu> mic: i think we need to think hard about the risk tradeoffs of counter modes.  they might actually be OK for Kerberos long-term keys given what information collisions leak
[00:07:02] <nico> we'd be talking about adding password change and ticket renew/refresh requirements
[00:07:32] <mrex-ietf> would it be possible for GCM/CCM and counter modes to not just derive nonces, but also derive the secret key?
[00:07:46] <nico> mic: our implementations would have to start implementing heuristics for when to change passwords/keys, renew/refresh tickets, ...
[00:07:50] <Tom Yu> mic: the only really sensitive thing encrypted in a long-term Kerberos key is a session key
[00:07:53] <nico> mic: I find that to be too much
[00:09:17] <nico> mic: keep in mind too clients that have low entropy to start
[00:09:46] <nico> mrex-ietf: yes, that's my proposal, but that effectively requires changes to RFCs 3961 and 4120, which is why I mentioned that earlier
[00:10:22] Karen O'Donoghue joins the room
[00:10:28] <Michael Peck> mic: can we attempt to decide between the CTS and CBC proposals?  counter mode could be a separate additional proposal
[00:10:51] <Tom Yu> mic: i didn't realize i was an author
[00:11:03] <nico> sam: I'm happy to work on counter modes, but only if we're willing to update RFCs 3961 and 4120 -- I think that's going to take a long time, so I'd rather choose a CTS mode and be done
[00:11:32] <Rhys> want that mic'd, nico?
[00:11:34] <nico> mic: consensus call proposal: is the room/list opposed to confounded CTS?
[00:11:55] <nico> Rhys: hmm, no, thanks
[00:12:15] <nico> mic: consensus proposal 2: is the room/list opposed to explicit IV CTS?
[00:12:36] <nico> mic: consensus proposal 3: is the room/list opposed to explicit IV CBC?
[00:13:35] <> I think it would be nice if someone(TM)  could post a nice clear
summary to the list.  I'm not sure what would be in that summary,
[00:14:31] <nico> mic: sam: that's where I was going; I agree with going to the list or having a conf call
[00:17:09] <nico> mic: I'm not implementing at this time, so I am happy to return to it later
[00:17:12] <> (mic?) would review pkcross; probably wouldn't implement
[00:17:56] <nico> mic: I personally think that a non-shared password cross-realm keying protocol is *badly* needed
[00:17:57] <Tom Yu> mic: interested in solving the PKCROSS problem; not sure i like the current proposal due to implementation complexity and deployability concerns, but i'm willing to be convinced
[00:18:09] tsitkova joins the room
[00:18:17] <nico> mic: I personally think that a non-shared password cross-realm keying protocol is *badly* needed
[00:19:05] <nico> (that's not the same as a PKCROSS, mind you)
[00:19:06] <> The number of single-DES cross-realm keys I know about is pretty
[00:19:11] <nico> no need to mic that
[00:19:39] <jimsch1> I can do some review on this -- I did a lot of review for 6717
[00:19:46] <nico> i know, I need to get on channel-bound
[00:20:04] <mrex-ietf> @nico: an x.509-cert based cross-realm trust model requires frequent cert renewal where previously the lifetime of the trust would not self-destruct
[00:20:16] <Rhys> jim: do you want me to mic that? ;)
[00:20:21] <nico> mrex-ietf: read the I-D!
[00:20:36] <> I thought Jim was in the room...
[00:20:42] <nico> mrex-ietf: you're assuming too much :)
[00:20:47] <jimsch1> He is  = he is just slow
[00:21:09] <> Which draft requires a charter change? (I missed it)
[00:21:29] <nico> mic: so recharter if we must; but, really, we ought to have the charter include fixing errors in RFCs under our purview
[00:21:40] <nico> rechartering is a formality
[00:22:14] <nico> mic: IMO it's an error / oversight
[00:22:29] <> mic: "improvements to the GSS-API" is in the charter
[00:23:03] <nico> kaduk: thanks for checking :)
[00:23:17] <nico> fixing errors == improvement :)
[00:23:21] <>, first sentence.
[00:23:44] <> Well, I read it, since I commented on it.
[00:24:47] <nico> I've read it
[00:24:48] <> mic: do we want to poll about standards vs informational?
[00:25:06] <nico> developer-friendly GSS docs have long been in our charter
[00:25:11] <Tom Yu> mic: authentication-indicator is one way to get LOA indication into authdata, and i think it's in charter (or authdata in general is)
[00:25:38] <> Okay.
[00:25:42] <nico> I think it should be Informational
[00:25:44] <ghudson> I've also read it and made comments.
[00:25:47] <nico> we're not changing anything
[00:26:42] <Rhys> anything else for open mic?
[00:26:46] <nico> kaduk: we want RFCs referencing RFC2743 to also reference yours for "and here's some easy to read description of how to use GSS"
[00:26:50] <> nico: Greg made a claim that the text in the -00 was changing
[00:27:22] <nico> kaduk: we'd have to make sure it doesn't
[00:27:34] <nico> oh, PRECIS
[00:27:36] <nico> ...
[00:27:57] <nico> mic: I don't think we reached consensus on that
[00:28:03] <> mic: might be worth re-sending a link to the kittne list about the
latest precis stuff
[00:28:11] <nico> Simon and I disagreed with something fundamental
[00:28:35] <jimsch1> How fundamentl
[00:29:30] <nico> jimsch1: we didn't think that the profile should define equivalence classes for strings
[00:29:30] <Rhys> all done
[00:29:34] <nico> IIRC
[00:29:40] <> Rhys: you're free :)
[00:29:44] <nico> for usernames, excuseme
[00:29:51] <ghudson> So, now that I can't consume any meeting cycles:
[00:29:57] m&m leaves the room
[00:29:58] m&m joins the room
[00:30:07] <Rhys> freeeeeeee
[00:30:41] <ghudson> I'm not really interested in an enctype which can't be used for long-term keys.  So from my point of view, unless Sam is right and CTR mode can be used safely enough for keys of any size, there isn't much reason to pursue CTR.
[00:30:57] <nico> ghudson: +1
[00:30:58] sftcd leaves the room
[00:31:28] <ghudson> I have given some thought to Sam's arguments, but I think CTR for long-term keys would face an uphill climb for acceptance.
[00:31:57] <nico> Sam asked about math analysis re: reuse, but I submit that we can't do that analysis without making assumptions about clients (like their RNG capabilities)
[00:32:26] m&m leaves the room
[00:32:28] <ghudson> You can make probabilistic arguments that counter collision wouldn't really be a big deal (if you assume good PRNGs), but convincing people of those arguments each time you're advancing the enctype would be tough.
[00:32:28] Scott Cantor leaves the room
[00:32:50] <ghudson> If you assume bad PRNG, then you have trouble with session keys.
[00:32:55] <nico> I mean, I know that low entropy affects existing clients too (after all, they must at least select a confounder)
[00:33:54] <nico> perhaps the correct approach is to exclude low-entropy clients from consideration because they are screwed no matter what
[00:34:15] <nico> in that case, then how many bits of counter and how many bits of nonce do we need?
[00:34:27] <Tom Yu> nico: i don't like that kind of thinking.  we need to have a more nuanced risk analysis of imperfect randomness
[00:34:27] <nico> nonce bits == 128 - counter bits
[00:34:33] <mrex-ietf> weren't client-suggested subsession keys xor'ed with KDC generated session keys?
[00:34:34] <ghudson> In MIT krb5 we do make some allowances for low-entropy clients, basically feeding cryptographic secrets from the server end into the PRNG generator to attempt to feed of some of their randomness.  I don't know if we get much mileage out of it.
[00:34:51] <nico> Tom Yu: well, that's why I used the weasel word "perhaps"
[00:35:18] <ghudson> mrex-ietf: No.
[00:35:32] <ghudson> Unless I've had a terrible memory lapse.
[00:36:06] <ghudson> I believe the ticket has a session key, and then the client optionally proposes a subkey in the ap-req, and then the server optionally proposes a different subkey in the ap-rep if mutual auth is performed.
[00:36:06] Rhys leaves the room
[00:36:09] tsitkova leaves the room
[00:36:16] <ghudson> And all of those keys are independent.
[00:36:32] <mrex-ietf> I had the impression that Ted Ts'o once said that rfc1964 subsession keys suggested by the client were xor'ed with the service tickets session key from the KDC
[00:37:02] Michael Peck leaves the room
[00:37:07] <nico> mrex-ietf: they aren't
[00:37:38] <Tom Yu> anyway i think if we want Suite B enctypes, CTS is going to reach consensus much more quickly than a counter mode
[00:38:06] Rhys joins the room
[00:38:12] <nico> Tom Yu: perhaps what we should do is figure out how long till a long-term key is compromised by low-entropy clients using either cipher mode
[00:38:15] <nico> then compare
[00:38:44] <nico> in order to do that we need to have some clue as to max amount of data to encrypt with a given key and IV because we need some bits for counting blocks
[00:38:52] <nico> well, we don't have to do that
[00:38:59] <mrex-ietf> for rfc4121, isn't the server asserting an new subsession key in AP_REP and overriding the client's subsession key?
[00:39:12] <Tom Yu> nico: clients don't encrypt very much with their long-term keys
[00:39:32] <nico> mrex-ietf: yes, that is so -- no XOR there
[00:40:14] <nico> Tom Yu: if we have to set aside bits for counting blocks then we'd be imposing a max PDU size; OTOH, I think we *don't* have to set aside bits for counting blocks, we just pick a 128-bit IV randomly and start counting from there (with wraparound)
[00:40:44] <> Yeah, CTS would probably reach consensus faster than CTR.  Would CBC
be able to reach consensus at all?  I sort of think it would not...
[00:42:02] <nico> kaduk: I don't think we're likely to reach consensus for CBC
[00:42:11] <nico> we're making this way harder than it needs to be...
[00:42:43] <nico> merely doing encrypt-then-MAC with some new hash/MAC, updating the KDF, and keeping everything else the same would be easy
[00:43:00] <nico> we should go for easy-but-great improvements
[00:43:08] <nico> we can go for even better improvements later
[00:43:33] <> <sarcastic>but then we'd risk running out of enctype
[00:43:37] <nico> we might need to re-introduce a notion of enctype similarity...
[00:43:52] <nico> kaduk: the bigger concern is KDB entry size
[00:44:06] <> nico: why is that?
[00:44:29] <ghudson> If the client's subsession key is critically weak, it doesn't help that the server overrides it.  The ap-rep will still be encrypted in the weak key and an attacker could decrypt it to get the acceptor subkey.
[00:45:12] <Tom Yu> well then we mitigate using forward secrecy ;-)
[00:45:20] <nico> kaduk: for operational reasons?  It's at least more important than your [facetious] concern about running out of enctype numbers! :)
[00:45:47] <nico> Tom Yu: PFS requires entropy on the client side
[00:46:28] <nico> nothing can make up for lack of entropy on the client side -- we can only talk about how quickly security degrades given any one enctype in the face of low-entropy clients
[00:46:39] <> Like, size of database on disk, or the time needed to string2key all
the enctypes, or using up entropy for random2key keys?
[00:47:08] Tom Yu leaves the room
[00:47:10] <ghudson> <insert rant about how entropy cannot be "used up">
[00:47:14] <nico> kaduk: all of that + time to prop
[00:47:21] <> Greg: let me rephrase
[00:47:27] <nico> ghudson: huh?
[00:47:38] <> consuming time by reading more from the PRNG.
[00:47:51] <ghudson> Sorry.  I have a pet peeve about the Linux /dev/random.  It's not really topical.
[00:47:52] <nico> ghudson: I made that same rant on one of the crypto lists today, but I'm not sure what its relevance is here
[00:48:03] <mrex-ietf> how the client derives the (rfc1964/first) subsession key seems to be an implementation decision
[00:48:04] <> nico: I said "using up entropy".
[00:48:05] <nico> oh, i hadn't finished reading Ben's comment ;)
[00:48:39] <> nico: (different topic) I take it that you didn't finish reviewing the
gss-loop document before the kitten meeting, then?
[00:48:52] <mrex-ietf> shouldn't the client be able to use something like HMAC(ticket-session-key, some-nonce) at any time
[00:49:09] <nico> kaduk: I reviewed enough of it
[00:49:11] <nico> why?
[00:49:25] <> nico: I think the chairs would wnat you to send mail to the list,
[00:49:38] <nico> saying?
[00:49:42] <nico> that I am for it?
[00:49:48] <> That you read it, want it to be adopted, mumble.
[00:49:50] <nico> but I already said so here today
[00:49:56] <nico> ok, sure
[00:50:06] <nico> alright, I've slides to write for HTTPauth
[00:50:09] <nico> i should go
[00:50:09] <ghudson> mrex-ietf: Yes, client and server implementations can use the ticket session key when choosing their subkeys without any protocol changes, as long as they transmit the final result in the ap-req/ap-rep.
[00:50:56] <> I wonder what other gems I'll find as I go through 2743 carefully.
This bit where the first init_sec_context call can return
GSS_S_COMPLETE but a second is needed is pretty special.
[00:51:30] <nico> that's necessarily so
[00:51:38] <nico> kaduk: that's necessarily so
[00:51:53] <nico> and it's true on the other side as well
[00:52:05] Karen O'Donoghue leaves the room
[00:52:13] <mrex-ietf> "but a second is needed"?  huh?  if the context iterator function returns GSS_S_COMPLETE, then any further context level token must be passed to gss_process_context_token  -- NOT the iterator
[00:52:14] <nico> a party can think it's done and produce what it thinks to be the last context token
[00:52:16] <> nico: but it makes for special cases that I have to cover,which makes
the document longer and less simple.
[00:52:23] <> nico: how is it true on the other side as well?
[00:52:24] <nico> the other party can then fail and send back an error token
[00:52:40] <nico> kaduk: consider other numbers of tokens exchanged
[00:53:06] <ghudson> Where is this in 2743?
[00:53:11] <nico> e.g., for .5, 1.5, 2., *.5 round trips the initiator can be surprised by failure post-complete
[00:53:27] <mrex-ietf> should be in the description of gss_process_context_token()
[00:53:36] <nico> for 1, 2, 3, *.0 round trips the acceptor can think it's complete and then the initiator can fail
[00:53:50] <nico> yes, gss_process_context_token()
[00:53:56] <> mrex-ietf: the scenario I was reading about and considering is if a
mechanism specification allows for confidentiality protection to be
optional for implementations; if the particular mechanism provider
cannot provide confidentiality but it was requested, at least one
token must be sent from acceptor to initiator.
[00:53:59] <nico> which is also used for processing delete context tokens
[00:54:31] <> mrex-iet: so, maybe I mean process_context_token and not
init_sec_context, okay.
[00:54:42] <nico> the more interesting odd case is the anonymity thing
[00:54:54] <nico> where you must check ret_flags before sending the init sec context token!
[00:55:03] <> nico: where the initiator must refuse to send a token if it would lose
[00:55:40] <nico> yes
[00:56:02] <nico> you'd think that the mechglue/mechprovider would just fail if they couldn't provide anonymity
[00:56:19] <> "Well, we could change the spec and fix it" :)
[00:56:32] <nico> but it actually makes sense: it's an *optional* feature, you ask, then you must check if you got it -- that's the pattern in GSS
[00:56:33] <nico> and it's why channel binding is broken in GSS
[00:56:46] jimsch1 leaves the room
[00:56:48] <nico> kaduk: no, I think we need to keep the ask-then-check pattern
[00:57:07] <nico> we could add a layer of dev-friendly functions that do the check for you
[00:57:19] <nico> see Roland's libknc (which is really a GSS netcat)
[00:57:27] <nico> (and, actually, it's more than that)
[00:57:34] <mrex-ietf> ask-then-check is the only way that "negotiation" can reliably work (i.e. without having to go through a context establishment failure)
[00:58:22] <nico> mrex-ietf: for some things;  channel binding is all or nothing; some things aren't really negotiable in general (e.g., conf prot could be but never has been in GSS mechs)
[00:58:39] Rhys leaves the room
[00:58:51] <mrex-ietf> nico: I agree that channel bindings in rfc2743/2744 is defective
[00:59:14] <nico> mrex-ietf: GSS should lose a bit of generality; for example, SSPI allows the caller to get seq numbers from per-msg tokens, which is incredibly useful, but GSS allows the use of timestamps too (which no mech does)
[00:59:21] <nico> so GSS doesn't expose seq nums
[00:59:35] <nico> so things like RPCSEC_GSS have to implement their own seq num windows
[00:59:42] <nico> wasting precious bandwidth and cycles
[01:00:27] <nico> I think that's silly; we should add new per-msg token functions that allow the caller to get seq numbers (and possibly set, with local seq num windows to prevent reuse)
[01:01:15] <nico> anyways, back to cipher mode... Sam has convinced me that I my objection to counter modes was knee-jerk
[01:01:21] <mrex-ietf> nico: the problem with this is interop with installed base.  Sequence numbers provided by apps at app layer can be implemented interoperably with the installed base of gssapi mechs
[01:01:43] <nico> mrex-ietf: I'm thinking of future apps
[01:01:54] <nico> there's no reason they shouldn't get to reuse GSS mech seqnums
[01:02:40] <nico> and clearly it works for SSPI
[01:03:00] <mrex-ietf> if you're going through a tcp channel, strict sequencing, as is available from GSS-APIv2, is usually sufficient for the app
[01:03:20] <nico> mrex-ietf: but we have apps that don't do that
[01:03:26] <nico> consider, once again, RPC
[01:03:27] <nico> or
[01:03:32] <mrex-ietf> having to supply an explicit sequence number makes the API more complex  
[01:03:32] <nico> something new, like nanomsg
[01:03:35] <nico> or ZeroMQ
[01:03:46] <nico> no
[01:03:55] <nico> you'd NOT have to supply an explicit seq num
[01:03:57] <nico> you *could*
[01:04:12] <nico> and you *could* ask to get the seq nums of per-msg tokens you receive
[01:04:26] <nico> in addition to the existing GSS seq det svc
[01:05:19] <nico> however, if you can re-use the mech's facility you win big: you get back 64-bits/per-msg-token of wire bandwidth
[01:06:51] <mrex-ietf> the problem with the message sequence numbers at gss-api (with *ALL* gssapi mechanism implementations that I looked at) is that once you're out-of-sync, there is no way to recover from the error
[01:07:05] <nico> not true
[01:07:44] <mrex-ietf> for *ALL* mechanisms that I checked, including MIT Kerberos 5, this is what has been shipped!!!
[01:08:14] <nico> mrex-ietf: you might not care
[01:08:24] <nico> you might have an app with idempotence, for example
[01:08:48] <nico> and you might like seq nums just to drop really old msgs
[01:08:57] <mrex-ietf> I built an option into my gsstest for testing the behaviour of out-of-order message processing
[01:09:09] <nico> or msgs earlier than some barrier at which earlier msgs would no longer be idempotent
[01:09:35] <nico> there's zero reason not to expose this functionality
[01:10:01] <nico> sure, some implementations won't have it; but that's not a reason not to add this -- that's always true for all new functionality
[01:11:10] <mrex-ietf> As I wrote, I have yet to see an implementation that _does_not_ fatally on reordered messages
[01:11:18] <mrex-ietf> +choke
[01:11:20] <nico> they don't fatal
[01:11:36] <nico> MIT and Heimdal and MSFT's SSPs don't
[01:11:45] <nico> they return appropriate major status codes
[01:12:02] <nico> I'm not talking about apps that want octet streams
[01:12:11] <mrex-ietf> and after that, they keep returning error for EVERY further message!
[01:12:17] <nico> no
[01:12:22] <mrex-ietf> yes, sure
[01:12:34] <nico> if that were true then secure NFS would not work
[01:13:02] <nico> I mean, that's proof by existence Martin :)
[01:13:15] sftcd joins the room
[01:13:31] <> secure NFS is frequently doing the per-message operations in the
[01:13:34] <mrex-ietf> as I said, I tested it, and verified that it DOES NOT WORK
[01:13:48] <nico> mrex-ietf: dude, Secure NFS would not work
[01:13:55] <> (That is, from a different implementation than the userspace gss
[01:14:04] <nico> Solaris happily does Secure NFSv3 over UDP without panicing
[01:14:16] <mrex-ietf> maybe you're not requesting GSS_C_REPLAY_DETECT ?
[01:14:32] <nico> kaduk: if you remove the kernel module for GSS for Solaris then it will upcall to gssd for all per-msg token calls too
[01:14:38] <nico> mrex-ietf: duuh
[01:14:55] <nico> I told you, we're not talking about apps that want octet streams
[01:15:23] <mrex-ietf> Well, apps normally don't want to be faced with replays
[01:15:42] <nico> mrex-ietf: there are apps for which that's not a problem
[01:15:59] <mrex-ietf> If the app has to protect against replay itself, then there is zero benefit from being able to specify a sequence number to the message protection call
[01:16:08] <nico> I score that as "no objection to exposing sequence numbers"
[01:16:17] <nico> mrex-ietf: wrong
[01:16:23] <nico> scroll up and read what I wrote
[01:16:35] <nico> anyways, I gotta go
[01:16:37] <nico> bye
[01:16:39] nico leaves the room
[01:33:08] Karen O'Donoghue joins the room
[01:37:04] Karen O'Donoghue leaves the room
[01:48:38] ghudson leaves the room
[01:54:44] sftcd leaves the room
[02:11:37] mrex-ietf leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!