This is precisely the sort of thing that RFC 3195 attempted. You want
authenticated source? You can have it. You want authenticated server?
You can have that too. You can even have unauthenticated server with
authenticated client. As we've just released a revision draft, I
suggest people look that over. My guess is that the security
considerations and the choices made here will require at least some
additional review.
Please draft-lear-ietf-syslog-rfc3195bis-00.txt.
And that leads to my other question. Why are we implementing a separate
TLS protocol when 3195 and its successor both exists and has been
implemented? That seems to me rather redundant, and violates a tenant
that we really should observe more: don't reinvent the wheel.
Eliot
[EMAIL PROTECTED] wrote:
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
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
