-----BEGIN PGP SIGNED MESSAGE-----
At 01:16 PM 12/6/00 -0600, Chris M. Lonvick wrote:
>Hi John,
>I need to go through the protocol fields in greater depth.
>I havn't had time to wrap myself up with that yet but I did
>want to give you some feedback on some of your questions.
Okay, thanks.
...
>I personally consider fragmentation icky (technical term)
>but I don't think that it should impose restrictions on what
>we're doing.
Right. I don't see where we'll ever need to go over 1500
bytes, unless we're doing something ugly like appending a
4096-bit RSA signature to the end of each message.
>>g. One assumption I've made about key management is that
>>there's no negotiation between a sender and a receiver.
>>Instead, if the sender shares a syslog-auth key with the
>>receiver, it sends syslog-auth messages, otherwise, it
>>assumes the receiver is an old-style receiver and never
>>sends messages longer than 1024 bytes. I can't see any
>>other way for the sender to behave, since they may not be
>>able to negotiate.
>
>I think that you're asking if there is any way for the sender to
>have some assurance that the receiver is new-style and has the same
>key? I'd say that's an operational issue and shouldn't take too much
>space in your ID. I'd suggest that you just go with notes to say
>that both the sender and the receiver MUST have the same key for
>this to work.
Okay. The other issue is that the sender has to know which
receiver it's sending things to, in order for this whole
thing to work, and when the sender is being configured for
that, it needs to also be given the key to use.
...
>That makes sense to me. Again, we should just consider
>that the operations staff will know enough to not send
>new-style messages through an old-style grinder. We are
>focusing on transmission security, but I'll go along with
>anything that can add some 'extras' without adding too much
>overhead.
This makes sense. In fact, once we specify this, one of the
complicated areas of syslog-auth goes away.
>>b. Do we want to support encryption? I know how to do it,
>>and it's quite easy to add. But there are some questions we
>>ought to consider about it, such as what the rules are for
>>forwarded encrypted messages, and whether the messages ought
>>to be stored encrypted. And adding encryption along with
>>doing all the other crypto in separate messages leaves us
>>with some problems in terms of being able to decrypt the
>>messages. Also, while it's not too hard to leave the
>>messages in ASCII printable characters, it does cost
>>something in terms of performance of encryption engine.
>>(Basically, we can use AES-OFB to generate a pseudorandom
>>keystream for each message, and strip the high bit off from
>>the keystream bytes before XORing it into the syslog message
>>text.)
>
>I'd suggest not doing that at this time. If we're
>providing authentication and integrity at a level
>appropriate to the situation with your proposal, then the
>only thing that encryption would add would be
>confidentiality. I'd say that could be better handled
>through syslog-reliable.
Well, once we've done the key management for syslog-auth, we
ought to be able to do the encryption without much trouble.
There's nothing inherent in encryption that seems to me to
cry out for reliable delivery.
>>c. This doesn't discuss the signing method I posted about
>>before, but the signing method would be built on this
>>message format. We'd just send an occasional
>>syslog-auth-like message with message-text containing base
>>64 encoded message hashes from the previous 34 or so
>>messages, amid other normal messages. The format would be
>>simpler, since forwarded messages would no longer be dealt
>>with at all in our message format, and since key management
>>would be so much simpler.
>
>I kind'a liked that one. I'll leave it to you and the group
>to decide if:
>- it's not needed,
>- it would be a nice option, or
>- it's definitely needed.
> (Vote now! Every vote counts. :-)
The more I look at the two notes I've sent out, the more I
like syslog-sign. The simplifying assumptions made the
whole design much cleaner.
>>[[ Is there a reason to stick with md5 instead of SHA1? --JMK ]]
>
>None that I can think of. The appropriate use of MD5 has
>been documented in RFC-1321 and the appropriate use of SHA-1
>has been documented in FIPS 180-1.
Cool. I'm more comfortable using SHA1, since MD5 seems to
have fallen into the category of ``not quite broken for this
specific application.''
...
>>[[What standard should I reference? --JMK ]]
>
>RFC-2045
Thanks.
>Several other RFCs fill the MAC field with the shared
>secret or the session key before computing the MAC over the
>entire packet. Does that add anything to your proposal?
>(Being somewhat of an amateur cryptographer, I think that I
>know how to figure that out: ask a professional
>cryptographer. ;-)
Filling the MAC field with key won't make any difference in
security, if hmac-md5 is already secure. If it's not
secure, adding the key again may make it stronger or weaker,
and it's pretty much anybody's guess. (It depends on how
it's insecure.)
...
>>a. Should we somehow support future 128-bit IP addresses? This
>>might be a good use for another flag bit.
>
>Absolutely.
Okay. If I specify constant 128-bit IP addresses, this
works, right? (e.g., IPv6 can encode IPv4 addresses,
right?)
...
>It's called Network Address Translation (NAT). Having
>confusion about the original source address or any
>intermediary will have to be an anachronism of the
>operations and management of the network. I'd suggest that
>we not be concerned about it. If it becomes a concern of
>the future, it can be addressed through the RSIP effort.
>Since we are placing a MIC over embedded addresses,
>NATificators won't be able to change them without
>disqualifying the entire packet.
This seems completely reasonable to me.
...
>What happens when the counter rolls-over? I don't think
>that it needs a lot of special consideration, just an
>explanation.
I chose 48-bit counters so that this would never happen in
practice. I suppose that the real answer is:
a. When the global message counter rolls over, the sender
(device or relay) MUST immediately generate a new unique
session ID.
b. When the superincreasing reboot session ID rolls over,
the sender (device or relay) MUST have all its shared keys
changed.
In practice, this should never happen. But if it ever does
happen, it's critical that the reboot session IDs and global
counters never repeat.
...
>>a. Superincreasing -- session IDs of 48 bits chosen in a
>>way that guarantees that the session ID will never repeat or
>>decrease in successive reboot sessions.
>
>Never is a very long time. ;-) How about roll-over
>analysis? If the device is using time() for the counter,
>then it could fill all 48bits in several trillion years.
>Conscientious operators should make appropriate plans.
Okay, I'm a cryptographer, I should be used to planning for
unreasonable numbers in all directions.
...
>>[[ Okay, so is there actually an N for which this can be
>>relied upon to work? My fear is that there will be some
>>situations where the sender just sends one syslog message,
>>again and again. The recommendation for including any
>>internal clock or status flags that are available will still
>>ensure a unique session ID, but I don't think I can require
>>this. Comments? --JMK ]]
>
>I think you put in too much detail there. I'd suggest just
>writing that it is the responsibility of the implementor to
>get it right. If they don't get it right, then it will come
>out on bugtraq someday and they'll have an opportunity to
>_then_ get it right.
Okay, fair enough. The implementor's job is to choose an
appropriate N.
...
>>a. Should I add the destination address to the
>>authentication block? This would simplify some processing,
>>and guard against some not very important, but annoying,
>>attacks.
>
>I'm a bit undecided on that. What attacks would it prevent?
...
>I can't think that any good would come from detecting gaps.
>Since we're still using udp, there may be cases where
>packets arrive out of order. In the case of severe route
>changes between transmissions, we could have this:
...
Okay, see the discussion of this in syslog-sign. I think
what we really want is:
a. The ability to detect replays (or at least flooding
attacks) in real time.
b. The ability to detect gaps in the messages when we
review the log offline.
...
>>[[ Question: Can we guarantee that forwarders will only use
>>priority value to decide where to forward messages? I
>>thought the forwarders could decide to forward messages
>>based on other parts of the message. --JMK ]]
>
>There's the priority field and the message text. If there
>is anything else that can be used as a decision criteria
>then I'll have to rewrite syslog-syslog. ;-)
Right. I thought this through a little more clearly for
syslog-sign, where I basically said ``here's a parameter for
signature groups; it's the job of the person configuring the
device, collectors, and relays to ensure that all messages
in the same signature group go to the same place, and that
the corresponding signature group messages go to the same
place.
[[ Question: In syslog-sign, should I include a priority
field, to make life easier for installations that do their
routing of syslog messages based solely upon that field?
- --JMK ]]
>>e. Is the key ID in the Transmission MAC Block really
>>necessary?
>
>hmm.. Let's ask a cryptographer. ;-)
Yeah. That was mostly a note to myself, to carefully think
through whether there's ever a case where some machine
receiving this message won't know which machine generated
the authentication block. I'm inclined to leave it.
...
>>g. Should we include the original destination in the
>>original authentication block or the forwarder's block?
>>This might be useful when one sender's messages are arriving
>>at a final receiver by way of multiple forwarding paths.
>
>As always, if it's offered to me for free, I'll usually
>take it. ;-)
Yeah, there look to be two costs:
a. Bandwidth
b. Storage
There's also a more general cost to each option, in terms of
complexity of the whole scheme. You can see the extreme
points in syslog-auth and syslog-sign; in syslog-sign, I
basically made every simplifying assumption I could, and
promised as little as possible. In syslog-auth, I basically
included every option and special case I could. The problem
with this is that syslog-auth is way to complicated for a
security protocol, IMO. If you can't pretty-much hold all
the options and their implications in your head, then you're
in trouble when it comes to security protocols. I'm not
sure yet what to do with that; I can make the decription
much clearer, and the design much cleaner, and maybe this
will make the whole thing simple enough to really
understand. In the meantime, I'm much happier with
syslog-sign, and the experience of writing up syslog-auth
really drove my syslog-sign effort in a different direction.
- --John Kelsey, [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 Int. for non-commercial use
<http://www.pgpinternational.com>
Comment: foo
iQCVAwUBOjMMdiZv+/Ry/LrBAQHYUAP9EvFc4MlIqvVZ1rbqJKrLNs8Gqh47ySKP
A+PpFS4t8LIUzgnumZI2i9PmbJN/Q+d2+Uz04cZCBXr1iGnqfaeXIBasvWwYzwHZ
LPapNWI5kKt0274uTl6dbVPY8DyB7Bvc8YiUksWeYg/lZm33eFD2iysViBarFVeK
FpTOsrMaW5s=
=1gQh
-----END PGP SIGNATURE-----
