transport-tls should be designed to enable policy decisions. This group is
not able to make policy decisions. Some of this discussion is really
policy making. Policy discussions within syslog should be oriented towards
ensuring that any reasonable policy can be properly supported.
For example, in my real world situations, the primary policy concern is
disclosure of audit information to unauthorized recipients. This means
that the encryption aspect is most important, not the authentications. I
can deal with a degree of uncertainty about the source and destination
authentications.
If you look inside what authentication really means to us you find several
kinds of authentication to manage:
- Is the source machine authenticated and authorized to be on the network?
- Is the source machine/process authenticated and authorized to be a
source of audit information?
- The symetric questions for the destination machine.
My destination accepts all connections and has different processing
policies for incoming syslog information for the categories:
- unauthenticated machine source
- authenticated machine source, unauthenticated process
- authenticated machine source and process
The differences are a degree of confidence about various source
characteristics. No authentication ensures complete confidence, because it
is possible that both the source machine and process have been penetrated
by a hostile attacker.
The chain of trust to the various root certificate authorities is not
important. Suppose I get a good certificate signed by the ABA. What does
that mean? Does the ABA know what machines are authorized to be on my
network? no. It means that someone with good credentials paid the ABA
money to get a certificate for that identity. I will treat is as an
unauthenticated machine.
Suppose I get a certificate with a chain of signatures, the last of which
is my local hospital administration. All those earlier signatures mean as
little as the ABA signature. But that signature from the local hospital
administration means something. Now I will consider this machine to be an
authenticated machine source. (Process might still be unclear.) I don't
need the rest of the chain. A self-signed hospital administration CA is
good enough. This can save money and bother.
The source side rule gets even stricter. A hospital administration CA
signature is not enough. They sign all the internal machine certificates.
I need the cert contents to be right. Or, (more commonly) I demand that
the destination certificate match the single public cert that I provide to
authenticated source processes for logging. This cert is self-signed by
the syslog destination machine. The authorized internal machines and
processes use this to ensure that they have connected to the right
destination.
Now I have all three different categories that derive from my policies.
The chain of trust back to root CAs was not used much. What I really need
is just the portion to the CA for the hospital. It might happen to be
traceable to a root CA, but that doesn't matter in this situation. I can
even live without it on a small network, by inverting the relationship and
copying the self-signed public certs of the authorized source systems over
to the destination server. This doesn't scale well, but for small networks
it can be easier than setting up the local CA.
R Horn
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
