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.
--I just saw your posting with your replies to Darren. I'll look
that over soon as well.--
Thanks,
Chris
At 01:58 AM 12/4/00 -0500, John Kelsey wrote:
>0.1. Design Decisions
>d. The maximum message length is quite a bit shorter than
>Chris' proposed limit of 1500 bytes. Depending on other
>options, this might grow a bit, but won't get anywhere close
>to the 1500 byte limit unless we make major changes. My
>impression is that the maximum message length is only
>important in terms of keeping it below the MTU of most
>networks, so we don't end up sending multiple IP packets per
>message. [[ Is that right, or am I missing something?
>- --JMK]]
I personally consider fragmentation icky (technical term) but I don't
think that it should impose restrictions on what we're doing.
>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.
>0.2. Open Questions
>
>a. Would it make more sense to do all this in the same way
>I discussed for signatures? That is, the cryptographic
>authentication data is always sent in separate messages?
>This causes some problems (like requiring more memory on
>both the sender and the receiver, and leaving us with
>occasional messages we received but can't authenticate), but
>also ensures that we don't just strip off all crypto
>whenever we are sending long messages to an old-style
>receiver. It seems to me to make a huge amount of sense for
>storage security, but not for transmission security.
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.
>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.
>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. :-)
>1.0. Introduction
>1.1. Some things I haven't done
>1.2. Resource Requirements
>
>d. In this note, I assume no cryptographic mechanisms
>available except md5.
>
>[[ 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.
>2.0. Syslog-Auth Message Format
>2.1. General Formatting Issues
>2.2. Base 64 Encoding
>
>In the following description, we assume base-64 encoding for
>various fields. This is to be done according to whatever
>standard currently exists for base-64 encoding.
>
>[[What standard should I reference? --JMK ]]
RFC-2045
>2.3. The Authentication Block Format
>2.2.1. Transmission MAC Block (27 bytes)
>2.2.2. Storage MAC Block (27 bytes)
>
>The storage MAC block consists of the storage MAC key ID and
>the storage MAC. The key ID used is (naturally) that of the
>key used for storage security. The MAC is always computed
>over the original message text concatenated with the first
>authentication block held by the message, with all MAC
>fields set to eleven characters of ASCII zeros. Note that
>this happens even if the storage MAC is being computed by a
>forwarding machine several hops after the message was
>generated; the MAC is only computed over that original
>message and first authentication block, with all its MAC
>fields set to blocks of ASCII zeros.
>
>The purpose of the storage MAC block is to allow the use of
>a second key for storage security. This is necessary since
>a syslog-auth receiver with the key to a MAC stored can't
>use that key to provide any additional storage security.
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. ;-)
>2.2.3. Forwarding Block (9 bytes)
>b. The IP address of the first syslog-auth sender or
>forwarder, 32 bits, base-64 encoded in 6 characters.
>
>[[ I have two questions about this for the list:
>
>a. Should we somehow support future 128-bit IP addresses? This
>might be a good use for another flag bit.
Absolutely.
>b. Are there times when the IP address from which the
>message is received by a forwarder is an internal address,
>not a real IP address? It seems to me that this could
>happen, though it would be the result of a really dumb
>internal network configuration. (Like, people can use their
>own made-up addresses on an internal network, and could
>conceivably forward some messages out from that network.
>Right? Remember, I'm not much of a network protocol person,
>so I may be missing something.)
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.
>c. The number of times this message has been forwarded,
>0-4095, encoded as two base-64 characters.
hmmm... The most that I've ever seen was on the order of 4 or 5.
..however, 4095 will certainly quell any y2k-like issues.
>2.2.4. Destination Message Counter (8 bytes, base 64 encoded)
>
>This is a counter incremented only for messages the sender
>knows are going to the same destination. It is 48 bits wide
>in its raw format.
What happens when the counter rolls-over? I don't think that it needs a
lot of special consideration, just an explanation.
>2.2.5. Global Message Counter (8 bytes, base 64 encoded)
>
>This is a counter which is incremented and included for each
>syslog-auth message sent out since its last reboot. It is
>48 bits wide in its raw format.
Again, just note what happens when it rolls-over.
>2.2.6. Reboot Session ID (8-16 bytes, base 64 encoded)
>2.2.7. Flags (2 bytes, base 64 encoded)
>2.2.8. Version (2 bytes, base 64 encoded)
>
>[[ Should I be trying to put in more flexibility, here? --JMK ]]
Sounds OK to me.
>2.2.9. Cookie (8 bytes)
>
>[[ Is there a better string to use, to minimize the odds of
>an accidental collision? If we're constrained by bandwidth,
>then we could drop this to a two or three character string,
>and accept a higher rate of false positives. --JMK ]]
I think it's OK.
>2.2.10. Length of Messages
>3.0. Key Management Issues
>3.1. The Basic Scheme: One Key Per Sender/Receiver Pair.
>
>It would be possible to alter the syslog-auth spec
>slightly to include an encrypted key. In this case,
>whenever a sender was reconfigured to send message to a new
>receiver, it could be given an encrypted key to include in
>all messages to that receiver. This simplifies key
>management at the cost of longer authentication blocks. [[ I
>haven't done this because I don't think it's worth the
>trouble, but if there's a lot of disagreement on this, maybe
>we should discuss it. --JMK]]
Do you mean Public Key? I'd go along with that since there are a lot of
devices getting pub/private keys for SSL/TLS, IPsec, etc.
>3.2. Some Less Useful Key Management Options
>3.2.1. One Key per Sender
>3.2.2. One Key per Receiver
>3.2.3. Global Shared Key
>4.0. Sending Syslog-Auth Messages
>4.1. Overview
>4.1.1. Resources
>4.2. Setup and Configuration
>4.3. Reboot Sessions
>
>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.
>4.3.1. Superincreasing Session IDs
>4.3.2. Pseudorandom Session IDs
>
>[[ 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.
>4.3.3. Temporary Session IDs
>4.4. Building a Syslog-Auth Message
>4.4.1. Cookie (Required; 8 bytes)
>4.4.2. Version (Required; 2 bytes)
>4.4.3. Flags (Required; 2 bytes)
>4.4.4. Reboot Session ID (Required; 8 or 16 bytes)
>4.4.5. Global Message Counter (Required; 8 bytes)
>4.4.6. Destination Message Counter (Optional; 8 bytes)
>4.4.7. Forwarding Block (Optional; 9 bytes)
>4.4.8. Storage MAC Block (Optional; 27 bytes)
>4.4.9. Transmission MAC Block (Required; 27 bytes)
>4.5. Sending to Old-Style Receivers
>5.0. Forwarding
>5.1. Building the New Authentication Block
>5.2.2. Unauthenticated Message
>5.2.1.1.The Rest of the Authentication Block
>5.2.2. Authenticated Messages on First Hop
>5.2.2.1.The Rest of the Authentication Block
>5.2.3. Authenticated Message, Additional Forwards
>5.2.3.1.The Rest of the Authentication Block
>6.0. Receiver-Side Issues
>6.1. Description of Steps of Receiver Processing
>6.1.1. Notation
>6.2. Detecting, Parsing and Verifying
>6.2.1. Detecting Syslog-Auth Messages
>6.2.2. Parsing
>6.2.3. Verifying the Authentication Block
>6.3. Drawing Conclusions about Message Security
>6.3.1. Online Replay Detection
>6.3.1.1.Syslog-auth Messages with Replay Resistance
>6.3.1.2.The Replay Window
>6.3.1.3.New Session IDs and Discontinuities
>6.3.1.4.Detecting Replayed Session IDs
>6.3.1.5.Unauthenticated Messages and Replay-Vulnerable Messages
>6.3.1.6.Syslog-Auth Forwarded Messages
>6.3.2. Detecting Gaps
>6.4. Applying Conclusions
>
>[[ Should this stuff be in a standard at all? --JMK ]]
>
>Once the receiver has drawn conclusions about what can be
>guaranteed about a given message cryptographically, it needs
>to have a way of applying these conclusions. There are
>three ways this may be done:
>
>a. Writing conclusions out as an auxillary log file.
>
>b. Using the observations to change flags and such in
>forwarded messages.
>
>c. Using the observations to alter processing based on
>these messages.
You may want to move this to the "Security" section.
>6.4.1. Writing Out Conclusions about Syslog-Auth Messages
>6.4.2. Applying Conclusions in Forwarded Messages
>6.4.3. Applying Conclusions in Online Processing
>7.0. Reviewing Syslog-Auth Logs Offline
>7.1. Offline Replay Detection
>7.2. Storage Security
>7.3.1. Syslog-Auth Storage MACs
>7.4. Detecting Gaps by Reassembling All Paths of Forwarded
>Messages
>8.0. Conclusions and Open Questions
>
>There are a bunch of places where the protocol can be
>smoothed out or improved, sometimes just needing a little
>work, sometimes at the cost of increased complexity or
>resource requirements. Among these:
>
>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?
>b. Should I add support for IPv6 addresses? I think this
>is important to do, but I'd like some feedback.
Please do. It is important.
>c. Should we add some stuff to our handling of forwarded
>messages, to support online detection of gaps in forwarded
>messages? I think the only really smart way to do this is
>to optionally set up a different destination counter for
>each priority value on the sender side, and to set up a flag
>in the messages that denotes this. Then, a receiver can
>look at the destination counter on the inside authentication
>block, and look for gaps in messages sent by that sender.
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:
Order of Messages Order of Messages
Transmitted Received
A A
B C
C B
D E
E D
Would the receiver mark gaps between A-C and B-E? ..and would it also
discard B and D? I'd suggest that if the operators have a real concern
over this for part of their network, they should be using syslog-reliable.
In that case, out of order packets cannot happen and a gap could be
suspected between the local event messages of
BEEP session to XXX down
BEEP session to XXX started
I don't know if Darren and Marshall want to do anything more with that.
It could be that the sender using syslog-reliable may have some persistent
storage to keep messages that are not ack'ed until it can deliver them.
>[[ 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. ;-)
>d. Does it make sense to support permanent fixed session
>IDs with no replay resistance?
I would say yes but I can be easily dissuaded if anyone comes up with a
marginally good argument against it. I can see a case where someone has
to provision hundreds or thousands of devices quickly. The best way would
be to use a template for their configuration.
>e. Is the key ID in the Transmission MAC Block really
>necessary?
hmm.. Let's ask a cryptographer. ;-)
>f. Should we add awareness of reliable delivery? This
>would mean including another flag in the authentication
>block and another flag in the forwarding block, and it would
>allow an authenticated statement that the message had been
>sent over reliable delivery mechanisms.
Would that be best described here or as a redefinition of one of the
'reserved' flags in syslog-reliable. I'd prefer the latter but check
with Marshall and Darren.
>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. ;-)
>9.0. Acknowledgements
>10.0. Bibliography
