Places I've clipped are places I agree with. :-)
John Kelsey wrote:
> >wasn't changed. So you're 3/4ths the way there.
>
> I guess we mean very different things, here. TCP actually
> does something to make the delivery reliable, in the absense
> of an attacker sitting in the middle blocking messages.
Right. That's the other 1/4'th. Anyway, I think this can be summed up as
"talk it over at the WG", because right now I think it's just "some think we
need it, others are less sure", which is what the consensus process is all
about.
> Anyway, if we've decided we want to put authentication of
> some kind into machines that have to keep using UDP, and
> that may not have a clock or anything similar, I think we
> kind-of end up at syslog-auth, and that this is a reasonable
> place to end up.
Agreed. Obviously, if you're unwilling or unable to use TCP, syslog-reliable
won't do you any good.
> >What I understand syslog-auth to be giving you is
> >1) Knowledge of whether a message has been lost
> > (maybe, and with enough effort)
> >2) Assurance of the previous hop (as (3) above)
> >3) Replay prevention (as (4) above)
> > (uh, maybe. See below.)
> >4) Authentication of the originator, in spite
> > of comprimised relays
> >5) Storage security, in spite of comprimised
> > collectors.
>
> Right. Actually, (1) and (3) are guaranteed if the device,
> relays, and collector all implement them, and are really
> easy to get when messages are going directly from device to
> collector.
Or at least when *all* messages from a given device wind up at the same
collector. Otherwise, you have to at least gather all the logs to see what
you missed, unless you have destination counters too.
> >> >Consider that it's only a
> >> >collision if you actually *store* all the old session
> >> >numbers; consider how much memory it would take to even list
> >> >a sparse bit array with 2^96 entries in it. (I haven't done
> >> >this, but I expect it's rather large if you assume you have
> >> >(say) 2^32 bits set out of 2^96.)
>
> >> There are two sides to this.
> >> [...]
> >> The pseudorandom RSID might need to be a little smaller, but
> >> I hate to make it much smaller, since that will decide what
> >> anyone is allowed to use it for in the future.
> >
> >I just thought that if the maximum reasonable number of
> >session numbers is about 2^32, using 2^96 bits of selection
> >space is bigger than it needs to be. 2^64 is probably
> >plenty.
>
> Well, you run into the birthday paradox here. With 2^{32}
> pseudorandom 64-bit session IDs generated by a single device
> in its lifetime, we have about 2^{63} pairs of session IDs,
> and we expect one collision with probability a little less
> than 1/2.
But again, you're assuming you're storing 32 gigs of session IDs per device,
pre-compression. Either there are few enough session IDs that you can reduce
the size and still avoid collisions, or there are enough session IDs that
you'll have trouble storing them. Just something to think about.
> >Then I've missed the point of your statement that a C
> >library PRNG is inadiquate.
>
> The problem is in the seeding. C compilers usually use a
> linear congruential generator, which will have a 16 or 32
> bit seed.
Most I've seen have a 48-bit seed. But if this is what you mean, it might be
better stated that your PRNG ought to have a minimum of X bits of seed to
provide protection through Y reboots. If a machine is expected never to
reboot unless the lights go out (say), a 16-bit seed might be dandy, since
it expects maybe only 20 reboots over its lifetime. I just think a
clarification of the "no C library PRNGs" is in order.
> If there are 2^x key IDs being handled by a given collector,
> and the key IDs are n-bit random numbers, then the
> expected number of collisions is about 2^{2x-1-n}. With
> 2^{32} key IDs in use, you'd expect about 1/2 a collision,
> which means you wouldn't be surprised to see a collision.
With 2^32 key IDs in use, you've filled up the entire IPv4 address space.
:-) Add a footnote saying you're planning ahead for IPv6. ;-)
> Again, I suspect you're right--the fields are defined wider
> than they need to be. On one hand, that leaves a lot of
> room for expansion later; on the other, it wastes bits and
> bandwidth and disk space.
Yep. A balancing act that maybe needs to be considered a bit more, is all.
As I said, it's just bits.
> Right. The text should read ``when a message is received
> with no authentication,'' since what we care about in this
> context is what the relays can pass along about the message.
Better: "received with no verifiable authentication".
> Now, whenever a relay receives a message that's already been
> forwarded, it effectively ANDs its status flags (e.g. ``I would
> have detected a replay from the previous sender.'') into the
> status flags from the previous sender.
Ah. Makes sense.
> Imagine the same situation with syslog-reliable--a relay is
> compromised. Wouldn't the relay be able to do replays (and
> worse), assuming there's no shared key between the device
> and the collector?
Yes, true. Without shared key material between the two ends, it's very
difficult to automatically detect forged messages.
> My understanding of networking issues is mostly theoretical,
> but it seems to me that:
>
> a. It's not possible in principle to make a replay window
> big enough to handle all contingencies when we have
> arbitrary-length chains of relays.
>
> b. It is possible in practice to make a replay window big
> enough to handle nearly all cases that ever occur.
>
> Does this look reasonable to you, or am I missing something?
Yes, it looks right to me. I was just trying to come up with a theoretical
upper bound of some sort. The alternative is to put in a formula, which
would be basically "add up all the delays you expect to see along the
longest chain, add a little more, and make it that."
> This is a good point. I've been constraining my design by
> assuming that there's essentially no back-channel from the
> relay or collector back to the device. And that's true for
> general operations, but not for key management, where we can
> assume the use of sneaker-net as required.
Yes. And you need all the stuff in syslog-auth that you've put there, if
you're assuming no back-channel and hence no TCP.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Personal malapropism generator free with purchase!
