Hi Anton,
Thanks for your feedback!
Environment where active attack is concern:
The server is configured with certificate, but the client
is not to be
required to be configured with a certificate. The client
can generate
a selt-signed certificate by itself.
Why do you need a self-signed certificate here? What purpose
does it serve?
The client MAY use a self-signed certificate.
You are not proposing using it for client authentication
here, are you?
Not exactly. This is to explore various possible options with regard to
certificate, perhaps it is not necessary to appear in the specification.
What is that? Let's be more specific if you intend to put
this in the doc (same goes for names of these 3 scenarios).
I think this configuration does two things: encryption and
server authentication.
Active attack involves an attempts to change information by contrast with
passive attack. To be more specific, it is man-in-the-middle attack is this
case.
but is
vulnerable to client spoof.
Security insensitive environment:
Both the client and server are not required to be configured with
certificate and trust anchor. They generate self-signed
certificates.
Again, why do you need client self-signed certificate here?
It is very easy for deployment because almost there is no
configuration required.
Note this configuration is vulnerable to active attack.
More specifically, this configuration provides only
encryption, but no authentication.
Which configuration should be mandatory? I seems we need not a
mandatory configuration from the PoV of implementation, right?
However, we do need to mandate the implementation (both client and
server) to support certificate configuration, trust anchor
configuration, and self-signed certificate.
Let's separate what is required for implementation, and what
is required for deployment.
I think server MUST implement & be deployed with a
server-based certificates for this transport. Whether it is
self-signed or CA-signed can probably be left to a deployment
choice. If it is self-signed, then effectively no server
authentication is done, just encryption.
The other part is client authentication. I think the server
MUST support authenticating clients with certificates and
client authentication is OPTIONAL for deployment. The
minimum authentication that server MUST support is validating
the client certificate against trusted CA.
OK.
A more secure server MAY also want to implement a mechanism
which prevents an authenticated client from masquerading as
something else in the messages that it emits. For example,
1mln certs may be signed by the same CA, but we don't want
one client with one such cert to be able to masquerade as any
of the 1mln other clients. To accomplish this, the server
need to take client identity from CN field of the certificate
and either validate it against some field in syslog message,
or at least plug the CN value into the syslog message
structured data, so that admin can do whatever validation
he/she desires when needed.
I think it is good to describe this additional client
authentication consideration, but leave it as OPTIONAL. I
think we discussed standardizing a unique CN field value
before and it was not fruitful.
Standard syslog structured field name for CN value would be a
good idea.
Good idea, but I tend to not mix the content with its tranport. BTW, TLS
transport is hop-by-hop protocol rather than an end-to-end protocol, so it
will have difficulties to decide the content when the client is just a
relay.
We will need to specify a cipher suite (probably RSA-AES-CBC) for
inter-operatability,
We need to specify at least 2 because one of them may become
vulnerable after standard is released and software is deployed.
The client MUST advertise support of cipher suite X & Y.
Server will select the appropriate one based on its
configuration for the TLS session. Server should not be
forced to select one of those two. I don't think there is any
server requirement here.
As for specific cipher suites, it will probably be a religious debate.
Maybe IETF has a policy on this? I have seen one other
standard require these two:
* RSA_WITH_3DES_EDE_CBC_SHA
* RSA_WITH_RC4_128_SHA
RC4 is for stream application, does it apply to Syslog/TLS?
RFC4346 mandates TLS_RSA_WITH_3DES_EDE_CBC_SHA, however, I think 3DES is a
interim algorithm. Actually TLS 1.2 draft mandates
TLS_RSA_WITH_AES_128_CBC_SHA.
My only concern would be that at least one of them (or better
both) is popular enough to be in most of today's major TLS
implementations.
Regards,
Anton.
but probably we don't need to
specify different cipher suites for 3 various ssenarios because all
the scenarios above requires certificate for key pair generation.
Regards,
Miao
_______________________________________________
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
