BTW, did you mean for your reply to me to go to the list? I don't think it
did, so neither did this. But feel free to forward it or whatever.
John Kelsey wrote:
> >0.1 - You missed a design decision that I think ought to be
> >explicitly stated: The packets are going in the clear over
> >UDP. Almost all of what you address here is already handled
> >in syslog-reliable. Only the "storage MAC" is unique to
> >syslog-auth and not syslog-reliable. I.e., a great deal of
> >what this addresses really is reliability (in the sense of
> >getting the message safely to the destination without
> >alteration) rather than authentication (in the sense of
> >knowing who created the message). I worry a bit about having
> >two syslog protocols proposed with so much overlap.
>
> Hmmm. I see your point, but S-A doesn't really do anything
> for reliability in the sense of making sure your packets
> arrive, it just tells you whether they arrived or not, and
> guarantees that they weren't changed in transit and
> originated from the sender you expect them to have
> originated from.
Well, "delivered reliably" to me implies you know it arrived and you know
that it wasn't changed. S-A gives you "you know whether it arrived" and you
have a guarantee it wasn't changed. So you're 3/4ths the way there.
syslog-reliable guarantees that it gets delivered, that it wasn't changed in
transit, and that the previous relay/device is who you think it is. The only
things it doesn't guarantee are (1) storage security, and (2) messages
relayed thru a comprimised machine. In other words, it doesn't guarantee
that the message originated from somewhere other than where you are
receiving it from - the security only covers one hop.
> The thing that makes this so complicated
> isn't really the duplication of TCP in things like sequence
> numbers, it's dealing with huge numbers of options for the
> devices, relays, and collectors, and propogating verified
> statements from a chain of relays to the final collector.
>
> How does syslog-reliable handle forwarded information from
> an old-style device? My impression is that it doesn't do
> anything with it, because that's not the way you're supposed
> to use this stuff.
I'm not sure what you mean by "do anything". It doesn't modify it. It
receives it (reliably, securly, authenticatedly, etc) and passes it along.
It's not unreasonable to expect that a syslog-reliable relay could be set up
that can parse the types of "raw" messages it gets and extract out more
precise information such as the timestamp, process ID, etc and break them
out so they're easier to handle.
> And I'm inclined to think that this is
> exactly right. Our goal is clearly for people to move to
> syslog-reliable wherever possible, since that gives superior
> guarantees (e.g., instead of just noting where the missing
> messages are, we either have all the messages in sequence,
> or have evidence of a denial-of-service attack of some
> kind), and since we can then use two-way communications for
> key management and such. But I wanted to make sure that
> syslog-auth would be something that could be dropped in with
> a minimum of hassle, and which would provide a clear
> statement of guarantees about what could be said about the
> logs stored on the concentrator. And syslog-auth over TCP,
> or over some other reliable delivery mechanism, would (I
> think) provide the same kind of guarantees that
> syslog-reliable would.
Yes, that last is my basic complaint. :-)
> Anyway, I am writing up syslog-sign (I'll think of a better
> name) to deal with the whole totally in-band storage
> authentication scheme I described before. It's about ten
> times simpler, since I don't have to worry about
> transmission security at all.
Yes. I (personally) think the better way to go would be to have
"syslog-sign" that guarantees the message came from where it claims to have
come from and hasn't been changed (i.e., not unlike the "storage signature")
and use syslog-reliable for on-the-wire security and authentication.
Basically, what syslog-reliable already gives you is:
1) Delivery as reliable as TCP to the next hop.
2) Secrecy from on-the-wire observation (i.e., encryption).
3) Assurance (via shared password) that the previous hop
is who they claim to be.
4) Replay prevention (via nonces).
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.
I think the degree of overlap is high enough that it's worth discussing at
the WG.
I think if syslog-auth or syslog-sign or whatever did (4) and (5),
syslog-reliable could reference it as a recommended addition for
use with syslog-reliable, just as s-r now recommends TLS and SASL.
Recreating SASL/DIGEST-MD5 to run over UDP seems like more work than it
needs to be. I might be wrong, but it's something that should be discussed
live, I think.
> >4.3b - 96 bits is probably *way* overkill. My guess would
> >be that 2^-32 is far, far smaller than the probability that
> >someone missets the clock on a superincreasing counter and
> >generates duplicates that way.
>
> Hmmm. If the superincreasing session ID decreases, a
> collector or relay receiving messages with that session ID
> can legitimately just discard the messages. (This is the
> only way they can be certain of the ability to resist
> flooding attacks.) So this would be kind of a nasty failure
> mode.
One would hope that the relay or collector would issue its own squawk when
such a thing happened.
> This is another place where the relays add a lot of
> complexity. A collector can decide whether to discard
> replayed messages or keep them based on whether its disk is
> getting too full. A relay can't know anything about
> collectors that will eventually get this message (the
> machine the relay's sending to may also be a relay, so it
> doesn't even know where the message will end up). If the
> relay detects replayed session IDs, it pretty-much has to
> discard the replayed messages.
I don't think this last sentence follows as a consequence of the earlier
sentences.
> >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.
> >4.3.2 - I think the wording you're looking for is that the
> >PRNG needs to be cryptographically secure.
>
> That's close. I need a seed that has something like 96 bits
> of entropy in it, in the sense that I should expect to have
> to wait until I've seen on the order of 2^{48} independently
> generated seeds, before I see a pair that are equal.
> There's no need for cryptographically strong mechanisms to
> expand the seed or condense it. There's not even any need
> for the seed to be hard to guess, given other information
> like the time of reboot or what's going on on the device's
> local network. The only thing that's required is that we
> get a unique RSID.
Then I've missed the point of your statement that a C library PRNG is
inadiquate.
> messages, and there will be no way to distinguish them from
> fresh messages.
Ah. I understand.
> >4.4.8 - What is the advantage of having a longer key-id
> >than MAC? Why not 64 bits for each? [OK, you answer this
> >later, buy you might want to consider a footnote mentioning
> >that you answer this later. :-]
>
> Good point.
Actually, you answer it later. My statement was meant to imply "if 64 bits
is too big for me to brute force, why do I need 96 bits of key ID?" Later,
you answer that as trying to reduce the likelyhood of key-id collision. I
still think 64 bits is way plenty - that implies (if I understand the math
right) something like a 1/65000 chance of two machine having the same
key-id, *assuming* every single IPv4 address is in use at once and running
syslog-auth and all talking to the same collector.
> >5.0 - "When a message is received from an old-style
> >forwarder..." How does it know? Can I de-authenticate a
> >message by mucking with the source IP address as it goes
> >past me? If an old-style formatter changes nothing but the
> >IP headers, what is the vulnerability to continuing to trust
> >the authentication blocks? Otherwise, the IP headers should
> >be included in the MAC hash for the forwarders.
>
> I can receive a message that's got a valid authentication
> block, but whose key ID I don't recognize. In that case, I
> can't make *any* inferences from information in that
> authentication block. (The authentication block could just
> as easily have been generated by an attacker.)
>
> Also, I put a flag in there somewhere in the fine print that
> specifies that the sender (device or relay) thought it was
> sending to an old-style sender. Though I can't seem to
> think of a case where this would actually be useful, now
> that I'm looking at it. Hmmm.
>
> Anyway, the basic question a relay needs to answer about a
> message it's forwarding over syslog-auth is ``Do I have some
> reason to trust that this message hasn't been altered or
> replayed in transit to me?'' And it will embed its answer
> in a flag in the forwarding block, so that later relays and
> the final collector will know the answer.
OK, so it's not "when a message is received from an old-style forwarder..."?
It's really "when a message is received with an unrecognised key-id, it is
treated as if it came from an old-style forwarder..."?
> Each relay checks to make sure that the incoming message
> isn't being replayed, from the device or the previous relay.
>
> Here's the idea I'm trying to get across:
>
> (Device,Relay1) share a key and some context.
> (Relay1,Relay2) share a key and some context.
> (Relay2,Collector) share a key and some context.
>
> There's no reason to expect Device to share context with
> Collector or Relay2, or for Relay1 and Collector to share
> any context. There's no reason to even imagine that Device
> has any clue about the very existence of Relay2 or the
> Collector.
The problem is, someone breaks into Relay3, and replays messages from Device
directly into Collector. At this point, Collector is trusting Relay3 to not
forward the replays, right? Since it shares no context with Device or Relay1
that would let it detect this? Or if someone breaks into Relay1, they can
send all the replays they want, yes?
Even if the relays also numbered all the messages they sent (which I didn't
see in the spec, altho I might have missed it when I looked), if you rely on
only the relays to do replay protection, your relays become the points of
vulnerability.
> This is why I'm not too worried about using the subset of
> output bits as a sort of shortened hash, useful in this
> special context.
Ah, an interesting proof. Thank you.
> >Re knowing how far back to keep - Calculate the diameter of
> >your network in hops, multiply each by 255, and look at the
> >message number that many seconds old. Assuming your IP stack
> >actually implements the hop count in seconds as well as
> >hops, you should have a hard time getting a message older
> >than that unless many of the relays delayed it for a long
> >time. If you allow a relay to hold a message for an
> >arbitrarily long time, there's no guaranteed upper limit,
> >and hence no good way of giving a "reasonable" upper limit.
>
> Right. The big potential problem seems to me to exist if
> the relay holds big messages back for a long time, but
> happily sends along smaller messages right away. If many
> relays along a path do this, the message could end up
> arriving outside its replay window.
Yes, but I don't see any way to prevent this, if, as I say, the relays are
permitted to hold messages arbitrarily long. The calculation above gives an
upper limit on queueing delays, and is very concervative, with the hope that
the application-added delays are sufficiently small that they're absorbed in
the queueing delays.
I suppose one good use of this standard might be to specify what the maximum
delays are, then, or that such should be programmable, or that messages
arriving outside the replay window should get summarized periodically.
(I.e., once an hour, a relay generates a message saying "23 messages from
w.x.y.z arrived too late", allowing timers to be adjusted or replay-attempts
to be detected.)
> >Appendix A: It's not that hard to test, if you have the
> >source to the code. You simply put an "if" at the front if
> >the hash function that says "If the key is YADDA1 or YADDA2,
> >return a hash of 123". Then don't use YADDA1 or YADDA2 in
> >your real configuration. :-)
>
> Well, the test would have to deal with intelligent handling
> of colliding key IDs.
I'm sorry. I figured what you'd do is put the key into the device, and into
the relay, and when you put it into the relay, the relay would hash it into
a key-id and say "Hey, this key-id is already there!" In other words, the
relay already knows all the key-id's it can recognise, so when you configure
it to recognise a new one, that's when you squawk. Then the administrator
goes and picks a different password for the device.
I'm just arguing that 96 bits is too much, and 64 bits is sufficient. I'm
not arguing for really tiny key-id's.
> Actually, my plan was to design it so that the probability
> of this bad event ever happening is so astronomically low,
> that in practice we will be totally shocked if it occurs.
> This is exactly the same practice that people use for
> ciphers or hash functions or signatures. SHA1 hashes from
> almost arbitrarily long messages down to 160 bits. It's
> obvious that any message you choose is overwhelmingly likely
> to have a huge number of messages that hash to the same
> value. But the probability that a randomly-selected pair of
> messages will accidentally hash to the same value is so low,
> we never, ever expect it to happen in practice.
But the hash on messages is a bit different than the key-id's. You want an
astronomically low likelyhood of finding two messages with the same hash,
because the point is to keep you from changing the message. However, with
keys, if you can detect when you generate the key that the key-id matches an
already existant key, you just generate a new one.
On the other hand, it's just bits in the message.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no "P" on the end of "Winnie the Pooh."
