Hi Everyone,
I think that it may be good to take a few moments to assemble the pieces
and see where we're at with all of this. We have a lot of the concepts
and some of the mechanisms. Perhaps it would be worth going into a
scenario or two to see if we need some additional restrictions placed
upon the receipt or transport of the event messages.
Let's first quantify the sources of the event messages:
Traditional: This is the style of messages generated today. Let's go
with the assumption that these are the type described in
syslog-syslog-01.
Authenticated: This will be the style of message defined in the
authenticated message ID. It is under discussion, but I
think that we can safely say that it will have a mechanism
to authenticate the sender of the message and to ensure
the integrity of the message to the receiver.
Reliable: As described in syslog-reliable-01, there will be two
formats for the messages being transmitted. First, the RAW
profile will allow the transmission of any string. Second,
the COOKED profile will still allow the transmission of any
string but will also contain other elements.
Let's now quantify the nodes that may be placed into a network. I've broken
this up in the following table. Each line represents a scenario and the
capabilities. I've eliminated some of the non-useful examples (such as a
device that will receive Reliable messages but will only transmit/relay
Traditional messages. In the following table, I've shortened the nodes to
T=Traditional, A=Authenticated, and R=Reliable as described above. The
items in square brackets designate the receiver-to-sender order - such that
[TAR] would mean that the device may receive a Traditional message, convert
it to the Authenticated format and then transmit it via the Reliable
mechanism.
Sender Relays Collector Notes
T T T This is the style that we have today. There may not
be a relay and there is nothing contained within the
message to indicate that it has gone through any
relays.
T [TA] A This may allow a relay to wrap up a Traditional
message with Authenticated extensions. (This needs
to be explored in the ID.) The collector would be
given some assurance that the relay wrapped it up
properly and then it could be validated that it was
not tampered with during transmission from the first
relay to the collector. It may also be stored with
the MIC.
T [TR] R At this point, we have no way of doing anything
useful with the relayed message. There would be the
assumption that the received message would be
transported to the collector without errors, but then
it would be dropped onto the disk/paper/display in
the same manner as the Traditional messages are
currently dumped. I would suggest that this may not
be useful.
T [TAR] R IMHO, this may be a more useful situation. The relay
would be able to add the Authentication descriptors
that would be carried with it to the collector. The
[TAR]-relay would be able to receive the Traditional
message, wrap it into the Authenticated format (using
its own credential) and then forward it to the
Reliable Collector. It may be retained with all of
the Authentication descriptors.
A A A This hasn't been addressed yet but it seems that the
originating authentication material should be kept
all of the way through to the collector. The relays
should validate that the received message is properly
authenticated. If only the authentication material
from the originating message is kept, then all
subsequent relays and the collector would have to
know the credential of the originating device (shared
secret?).
A [AR] R This is going to be an interesting case. The
originating device would have the proper
authentication and integrity check that may be
validated by the first relay. Subsequent relays
may not have to validate the authenticity and
integrity of the message. The collector would be able
to validate the stored message if the credential is
known.
R R R Right now, the defined element "entry" is a syslog
message. If it is a traditional type, then we may
be relaying things securely but there will be no
post-storage authentication or integrity check. If
it is an Authenticated message type, then those
values will be transmitted within the BEEP channels
and stored for later validation.
[AR] R R Could this be a "best case"? The message would be
generated in the Authenticated format and transported
through either the RAW or COOKED profiles to the
collector. It will be stored with the Authenticated
attributes.
This brings up some architectural questions that I'd like to pursue.
1. Should some wording go into the Authenticated and Reliable IDs that
explicitly states what is to be done with messages received? Perhaps
the Authenticated relay must wrap the Traditional message into an
Authenticated format using its own credential (T-[TA]-A)? Perhaps the
Reliable relay must do the same (T-[TAR]-R)?
2. If we do that, should the COOKED profile contain elements in the DTD
for the parameters supported in the Authenticated format? ..or should
it be left as a clear string. Keep in mind that [AR] receiver should
validate the packet before accepting it. Once it is received by the
relay, it should have passed the authentication test. Would there be
any value in breaking out those values for additional purposes only
for subsequent transmission?
3. It has been proposed that the credential used to authenticate the
messages in the Authenticated proposal is a "shared secret". It also
looks like the provisioning of that will be manual. This appears to
be acceptable for how we're going about this and what we expect it to
do. However, if we utilize the Authenticated format for messages
generated by the Reliable devices, then I don't think that manual
provisioning of the shared secret is desirable. Should a separate
exchange be used between the Collector//Relay, Relay//Relay and
Relay//Device to pass up/down the shared secret? If we're going to
go to that length, should we expand the credential to include a
Certificate? The Device could even generate a self-signed certificate
and pass that along upwards to the Collector. The private key could
be used to authenticate the message and that could be validated with
the public key contained in the certificate. If needed, the Relays
along the path could validate the authenticity of the message using
the public key if they cache it. The Collector could do the same
but would probably need to store it for the case that the certificate
may not be available in the future. (Of course, having the self-signed
certificate on the same device as the signed messages would present
a potential vulnerability as an attacker could modify the certificate
and the messages. ..however, I would classify that as an operational
challenge and not something that we need to address. ;-)
Your comments and thoughts on this would be most welcome.
Thanks,
Chris
[EMAIL PROTECTED]
